Attribute log, asset-event and asset-state writes to the task attempt

[ashb]

Audit log rows, asset events and asset-state writers identified their task by
(dag_id, task_id, run_id, map_index). Once a loop pass or a clear can reuse
those coordinates for another execution, a row read back by coordinates points
at the wrong attempt. Retired attempts stay in task_instance under their own
UUID, so the UUID is the strongest anchor: a row resolves to the attempt that
actually acted, and keeps doing so after that attempt is retired.

Rows written before the upgrade only have coordinates. We leave them without
an attributed attempt instead of matching them to a guess, because a wrong
attribution is worse than none.

An attributed row's public map index comes from the try's pinned definition,
as it does everywhere else, and is NULL once the attempt row has been purged
because nothing is left to derive it from. The asset-state writer also records
its region id, region index and try number so it stays describable after cleanup
removes the attempt. The stuck-in-queued accounting counts log rows by attempt
UUID and falls back to coordinates only for sentinel-region rows, which are the
rows that can still be unambiguous by coordinates.

OpenLineage uses the attempt UUID as the run id of regional tasks so the
listener events, the lineage macros and downstream asset dependencies agree on
which run they describe.

Task notes need no new storage: a note hangs off the attempt UUID and a retired
attempt keeps its row, so the retain-notes migration from the earlier design is
not carried over.

---

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

• Yes (please specify the tool below)

---

• 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.