API: Return asset events for Dag Runs without a start date

[rino0601]

Return asset events even when a created Dag Run has not started.

Asset-event responses serialize linked Dag Runs through API models that treated start_date as required, although queued and cleared Dag Runs may have a NULL value. Align the Core API and Execution API contracts with their generated UI, Task SDK, and AirflowCTL clients.

Add regression coverage for Core /assets/events, upstream asset events, the Execution API, and client response parsing.

closes: #71360

Tests:

• breeze --python 3.10 --backend postgres run pytest airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_assets.py -q
• breeze --python 3.10 --backend postgres run pytest airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_dag_run.py airflow-core/tests/unit/api_fastapi/execution_api/versions/head/test_asset_events.py -q
• breeze run --python 3.10 --backend sqlite pytest task-sdk/tests/task_sdk/api/test_client.py -q
• breeze --python 3.10 --backend sqlite run pytest airflow-ctl/tests/airflow_ctl/api/test_operations.py::TestAssetsOperations::test_create_event -q
• prek run --from-ref main --stage pre-commit --skip generate-openapi-spec --skip generate-tasksdk-datamodels --skip generate-airflowctl-datamodels

---

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

• Yes — Codex (GPT-5)

Generated-by: Codex (GPT-5) following the guidelines

---

Drafted-by: Codex (GPT-5) (no human review before posting)

[rino0601]

Hello, maintainers. Thank you, as always, for the project.

I saw that PR #71361 had been created for the issue I reported, but it felt like something was missing. So I checked out the project myself and gave it a try, taking care to follow the generative AI contribution guidelines.

Reading English is easy for me, but writing it is not, so I got some help from AI.

The changes allow null for the problematic part, and I also found all the parts with the same meaning and made them allow null as well. I passed all the static checks in the Breeze environment.

I wondered whether this might conflict with the original intent, so I used git blame on the places containing start_date and compared them with the intent of the previous PRs. At least, I found no intention in those PRs to make it required. That is why I opened this PR.

I live in the Asia/Seoul (+09:00) time zone, and I can contribute to open source every day between 22:00 and 00:00 in my local time. If I missed anything or if you need any help, please feel free to let me know :D

[github-actions]

uv.lock on main just moved via commit 1e1dc10 and this PR currently conflicts.

Quickest fix:

git fetch upstream main && git rebase upstream/main
rm uv.lock && uv lock
git add uv.lock && git rebase --continue
git push --force-with-lease

Automated nudge — ignore if you're not ready to rebase. This comment is updated in place on future uv.lock bumps.

[choo121600]

Looks good to me, thanks! :)