Resolve live producers by region and read their XCom by attempt

[ashb]

Once a loop body or a mapped region can hold several live task instances with
the same task_id and map_index, a consumer can no longer find its producer from
(dag_id, run_id, task_id, map_index) alone, so the lookup has to know where the
caller sits: in the same iteration, in the previous one (what a loop body means
by "the last result"), outside the loop, or in an explicitly named region. When
more than one live candidate still fits we have no sensible option to raise
an error.

Only live (non-archived or superceded) try are candidates, and their data is
read by UUID. An archived try keeps its XCom under its own UUID, so reading by
the resolved try is exact and cannot revive data from work a clear replaced.

Callers that predate regions must see what they saw before, so the default read
scope stays the sentinel region and regional rows appear only when a caller asks
for them. Lookups of earlier runs refuse a non-sentinel region because a region
belongs to a single Dag run, so the producer has to be resolved again for each
run.

The scheduler detected changes to upstream state and tracked map-length
revisions by TaskInstanceKey, which cannot tell two regions apart. One region's
expansion would have marked another's as changed, so both now key on the attempt
and on (task, region).

---

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.