Report language-SDK tasks running while the runtime starts up

[jason810496]

• related: Add dag_bundle_name option to subprocess coordinators #70805 (comment)
• Depends on Extract supervisor heartbeat logic into a standalone Heartbeater #71102 get merged first (only the last commit is new here).
• Diff for early review: jason810496/airflow@refactor/task-sdk/extract-heartbeater...fix/coordinator/mark-running-before-startup

Why

The language-SDK subprocess coordinator left the task QUEUED until the runtime had connected back over the comm/logs sockets, so JVM boot, artifact discovery and the whole task_startup_timeout window were charged to [scheduler] task_queued_timeout, and a runtime that never started looked like a task nothing had ever picked up, with its stdout/stderr discarded.

How

Bring the coordinator path in line with the Python path: report RUNNING at the top of execute_task, before any worker-side preparation.

• The reported pid is the supervisor's own, because the server 409s any heartbeat or second start whose pid differs. execute_task computes it once and threads it into the RUNNING transition, the startup heartbeats, and the supervised process, where it seeds Heartbeater.pid: the one value every later heartbeat reads, so they cannot drift.
• The preparation window now heartbeats (new _heartbeat_until_monitored): a small thread paces the Heartbeater from Extract supervisor heartbeat logic into a standalone Heartbeater #71102, reusing the monitor loop's send and stop policy, so a slow launch is not reaped by [scheduler] task_instance_heartbeat_timeout. With no process to kill yet, the failure cap is left off and transient failures simply retry; a disowned run stops beating and is terminated by the monitor loop moments later.
• running_since is threaded from the transition into StartupDetails, so the task sees the start date the server recorded.
• When the runtime never starts, execute_task reports FAILED (or UP_FOR_RETRY per the run context) and returns a non-zero ExecutionResult, taking the ordinary failed-task path. Warm-shutdown handlers are held across the RUNNING window.
• Nothing changes on the wire, so no language SDK needs a change.

What

• SubprocessCoordinator.execute_task: report RUNNING before _build_execute_task_command, heartbeat through the launch, report the terminal state when the runtime never starts.
• ActivitySubprocess: extract the RUNNING transition into _report_running and accept an optional reported_pid, seeded into Heartbeater.pid for the transition and every heartbeat to read.
• _accept_connections: raise the new SubprocessStartupError (carrying the runtime's exit code) and write pre-handshake stdout/stderr to the task log instead of discarding it.
• Document in the Java / Go / TypeScript pages that the startup wait happens with the task already running and that the recorded pid is the supervisor's.

Not addressed here: _ResourceTracker.__exit__ still terminates only the direct Popen, so a launcher that forks the real runtime can orphan it on startup failure. A robust fix needs start_new_session plus a process-group kill and belongs in its own PR; this change reduces the exposure from up to three launch attempts to one.

No newsfragment: the coordinator feature is itself unreleased on main.

---

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

• Yes, with help of Claude Code (Opus 5) following the guidelines