Add XCom read access to callback supervisor comms channel

[seanghaeli]

Add read-only XCom access to the callback supervisor IPC channel, allowing
callbacks to fetch XCom values from upstream tasks via the same mechanism
used for Connections and Variables.

Motivation

PR #65269 added Connection, Variable, and MaskSecret comms channels to the
callback supervisor. XCom was deferred because it requires explicit dag_id,
run_id, and task_id (callbacks have no implicit task context). This PR adds
that missing piece.

Changes

• Add GetXCom to the CallbackToSupervisor union type
• Add handle_get_xcom shared handler in request_handlers.py
• Route GetXCom messages in CallbackSubprocess._handle_request
• Add tests for both basic XCom fetch and fetch with map_index/include_prior_dates

Only read access (GetXCom) is exposed. SetXCom and DeleteXCom remain out of
scope for callbacks since they should not be producing XCom values.

related: #65269

---

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

• Yes — Claude Code (Opus 4.6)

Generated-by: Claude Code (Opus 4.6) following the guidelines

[ferruzzi]

What is the plan for plumbing the dag_id, run_id, etc through here? You don't seem to have addressed thr "motivation" part of your description. The reason I didn't include this one in the initial batch of comms channels was because GetXCom requires those and I didn't want users to have to manually provide those like XCom.get(dag_id=context["dag_id"], run_id=context["run_id"], task_id="upstream_task", key="return_value"), it should work the same way as a task so that context info needs to get provided "magically" somehow.

[seanghaeli]

Good question. The plan is for PR #66608 to provide the context plumbing — once a callback has access to dag_id and run_id via its context (either through the triggerer supervisor or executor subprocess SUPERVISOR_COMMS), XCom.get() inside a callback can use those automatically rather than requiring the user to specify them manually.

So this PR gives the mechanism (XCom comms channel), and #66608 gives the identifiers. Once #66608 lands, we can add a convenience wrapper that pre-fills dag_id/run_id from context. For now, the user passes them explicitly — still useful for callbacks that know which task's XCom they want to read.

[ferruzzi]

In #66608, you and Kaxil discussed and changed the scope of token:workload and this looks like it might need to be re-applied here? I'm not sure have a look and make sure the security concerns you two discussed over there aren't being undone here. I think it'll inherit the fix from over there, just make sure when you rebase onto that one that you test it.

That said, approved with the caveat of the follow-ups that were discussed and the fact that the CI is currently failing in main.

[seanghaeli]

Parking this as a draft pending a security-model decision raised on #66608.
This PR's mechanism is "let a token:workload-scoped token read XCom from a deadline callback subprocess." On #66608, @ashb pointed out that broadening token:workload to read data is a security regression. Circling back to this when the security problem in 66608 is addressed