Scope XCom Execution API to teams in multi-team mode

[o-nikolas]

XCom was the only shared resource without team isolation at the task api level. Any task could read, overwrite, or delete another team's XCom. Enforce team ownership so reads are allowed for the task's own team or global dags, and writes/deletes only for its own team, matching team-scoped variables/connections.
No cross-team sharing at this time. Gated on the multi_team setting (no-op when disabled).

---

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.

[vincbeck]

Code LGTM. The only question I have is, is this a multi-team issue? By that I mean, should a Dag access xcoms from another Dag (regardless of teams)? Should not we ensure any task from a given Dag can only access xcoms from this exact same Dag?

[o-nikolas]

Code LGTM. The only question I have is, is this a multi-team issue? By that I mean, should a Dag access xcoms from another Dag (regardless of teams)? Should not we ensure any task from a given Dag can only access xcoms from this exact same Dag?

I think cross dag xcom is a pattern that people make use of today. We could consider reversing that, but we'd have to reckon with the level of breaking change that would be and is a much larger discussion. I think the best short term path forward is to block the access cross teams for now to maintain the same behaviour that we have today.

[ramitkataria]

Looks good to me and I also agree with this being the best short term solution

[seanghaeli]

Noting that this will force a rebase in #66611 since they touch the same paths (or a rebase here if #66611 merges first).