Record mapped_length for Java SDK tasks with mapped dependants

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

https://github.com/apache/airflow/pull/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 https://github.com/apache/airflow/pull/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 https://github.com/apache/airflow/pull/70570 and https://github.com/apache/airflow/pull/70571
- Python reference: `_push_xcom_if_needed` in the task-SDK task runner