Record mapped_length for TypeScript SDK tasks with mapped dependants

[jason810496]

Background

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

#70571 introduces the server-derived TIRunContext.has_mapped_dependants flag; when set, the supervisor records mapped_length = len(value) on the return-value SetXCom on the task's behalf.

What needs to happen

1. Verify the supervisor-side recording from Bind mapped stub-task arguments in the Go SDK runtime #70571 applies to the NodeCoordinator path unchanged (it should, being supervisor-side rather than runtime-side).
2. Surface hasMappedDependants on the TypeScript TaskContext where useful to handler authors, following the existing camelCase mapping convention.
3. Cover the flow end to end: a TypeScript @task.stub returning an array, with a downstream Python .expand() over it.

Acceptance criteria

• A TypeScript stub task whose return value feeds a downstream .expand() causes those dependants to expand to the array's length.
• A TypeScript task with no mapped dependants records no mapped_length (no behaviour change).
• The camelCase to snake_case mapping for the new field is covered by the existing schema-mapping test suite.

Context

• Depends on Support dynamic task mapping on stub tasks #70570 and Bind mapped stub-task arguments in the Go SDK runtime #70571
• Schema-mapping test suite: Add TypeScript SDK coordinator schema-mapping tests #69297