Populate partition_date when manually triggering partitioned Dags

[Lee-W]

Why

When a Dag with a partitioned timetable (e.g. CronPartitionTimetable) is manually triggered with a partition_key, the run's partition_date was left NULL. Both the manual-trigger code path (_trigger_dag) and the core API route only forwarded the partition_key without deriving the corresponding date, so manually triggered partitioned runs ended up missing the date that scheduled runs carry.

What

• Add Timetable.resolve_partition_date(partition_key) to the timetable protocol (timetables/base.py). It guards on partitioned / partitioned_at_runtime and delegates to _decode_partition_date, whose default returns None.
• Override _decode_partition_date in the partitioned timetables:
  • CronPartitionTimetable (timetables/trigger.py): inverts _key_format via strptime and localizes the result with make_aware; raises InvalidPartitionKeyError on parse failure.
  • PartitionedAssetTimetable (timetables/simple.py): collects to_partition_date(key) from each asset mapper and returns the value only if all temporal mappers agree; otherwise, None.
• Add InvalidPartitionKeyError(ValueError) (exceptions.py) for invalid partition keys.
• Wire the resolution into both manual-trigger paths so partition_date is populated on all manually triggered runs:
  • api/common/trigger_dag.py resolves the date and passes it to DagRun.create_or_update_dagrun as partition_date=.
  • api_fastapi/core_api/datamodels/dag_run.py (TriggerDAGRunPostBody.to_trigger_params) resolves it and includes partition_date in the
    returned params; the public route (routes/public/dag_run.py) forwards params["partition_date"] to DagModel.create_dagrun.
• Translate the domain error at the FastAPI route boundary: execution_api/routes/dag_runs.py catches InvalidPartitionKeyError and returns HTTP 400.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: [Claude] following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[github-actions]

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.3.1 based on: backport label targeting v3-3-test
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker db9fa42 v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.