Bind mapped stub-task arguments in the Java SDK runtime #71060

Background

#70570 makes the execution API derive a per-map-index arg-binding spec for a dynamically mapped @task.stub, so a foreign runtime receives its element rather than the aggregated upstream output. #70571 implements the Go-SDK consumer; the Java SDK has no equivalent.

XComArgBinding carries two selectors the unmapped path never sets:

• map_index — pull the upstream XCom row at that index (expand over a mapped upstream).
• element_index — pull the unmapped upstream row, then take element N of the resulting sequence (expand over an unmapped upstream's list output).

Literal expands are resolved to their element server-side and arrive as plain literals, so the binding surface itself is unchanged from the unmapped case.

What needs to happen

1. Extend the Java SDK's arg-binding resolution to honour map_index and element_index, with typed and out-of-range errors that fail the task before its body runs.
2. Keep the unmapped path unchanged: a binding with neither selector takes the whole value.
3. Add an example mapped Dag to the Java example bundle and cover it with an E2E test.

Acceptance criteria

• A @task.stub expanded with .expand() delivers the correct per-index element to the Java task for all three expand forms (literal collection, unmapped upstream's list output, mapped upstream).
• Multiple expanded kwargs (the cross product) bind correctly, including mixed expand sources in one call.
• .partial() literals and unmapped-upstream XComs bind identically on every index.
• Out-of-range or type-mismatched selectors fail the task loudly rather than silently zero-filling.

Context

• Depends on Support TaskFlow call syntax on stub tasks for the Lang SDK #69757 and Support dynamic task mapping on stub tasks #70570
• Go parallel: Bind mapped stub-task arguments in the Go SDK runtime #70571
• Java-side arg binding for unmapped stub calls: Java SDK: Register tasks as first-class TaskDef objects #71057