Record mapped_length for Java SDK tasks with mapped dependants

[jason810496]

Background

A Java task's return value cannot currently feed a downstream .expand(). The Python task runner does this in _push_xcom_if_needed, but a foreign runtime cannot inspect the Dag to learn that its output has mapped dependants.

#70571 introduces the server-derived TIRunContext.has_mapped_dependants flag (computed from iter_mapped_dependants); when set, the supervisor records mapped_length = len(value) on the return-value SetXCom on the task's behalf, so the scheduler can expand the dependants.

What needs to happen

1. Confirm whether the supervisor-side recording from Bind mapped stub-task arguments in the Go SDK runtime #70571 is language-agnostic. If it is, this issue reduces to Java-side verification plus tests; if any of it is Go-specific, lift it into the shared coordinator/supervisor path.
2. Ensure the Java SDK surfaces has_mapped_dependants on its context object where it is useful to task authors.
3. Cover the flow end to end: a Java @task.stub returning a list, with a downstream Python .expand() over it.

Acceptance criteria

• A Java stub task whose return value feeds a downstream .expand() causes those dependants to expand to len(value) instances.
• A Java task with no mapped dependants records no mapped_length (no behaviour change).
• The version gate is respected: pre-arg-bindings clients skip the derivation entirely.

Context

• Depends on Support dynamic task mapping on stub tasks #70570 and Bind mapped stub-task arguments in the Go SDK runtime #70571
• Python reference: _push_xcom_if_needed in the task-SDK task runner