fix(producer): a render whose capture stops advancing fails within minutes - #6257

What changes for users

A render whose capture stops landing frames now fails in minutes instead of sitting silent, and a request that is alive but quiet now says so. When a capture attempt stalls, the existing retry (fewer workers, fresh session) still runs; the render fails only when every attempt has stalled.

How

• One stall rule in observeRenderStage, fed by job.framesRendered (every capture path writes it). A capture attempt is aborted after 300 s without a first frame, then 60 s without a new frame (HF_DE_STALL_MS overrides the 60 s). It covers parallel and sequential disk capture, HDR sequential and hybrid, and distributed chunk capture. Stages that already had their own stall guard (sequential streaming, worker-encode, segmented, parallel streaming) are unchanged.
• The trip aborts only that attempt, and is classified exactly like today's per-call capture timeout, so the existing ladder runs: parallel disk capture halves its workers (4 to 2 to 1) when the stalled attempt landed at least one frame. Sequential disk and HDR have no retry for this, as with the timeout today. Each attempt gets a fresh window. When the last attempt also stalls the render fails with RENDER_STAGE_STALLED (owner system, retryable: false), added to the server's safe error codes so it reaches the wire. An aborted attempt that neither retries nor settles within one more window fails the stage.
• 30 s keepalive on /v1/render-stream: from before the queue wait until just before the final event, it re-sends the normal progress event with the live stage and frame counts. It never sends after a terminal event.
• Bounded ends: the final event flush gives up after 10 s, closing a capture session no longer waits forever on the last browser memory sample (5 s cap), and the render slot is released when the render ends rather than after the final write, so a client that stops reading cannot hold a slot.
• Two stale fallow comments in frameCapture.ts removed (the gate fails on them).

Package size

scripts/package-size-budgets.json: the producer budget goes from 781312/2840135 to 787935/2862300 (packed/unpacked), main's budget plus this change's measured delta. Measured: main 787145/2860280, this change 793768/2882445. The change sits inside the 1% tolerance of the new budget.

Verification

• New tests go through executeRenderJob (real disk capture stage and ladder, only the parallel capture call scripted), renderChunk, and createRenderHandlers. Run against main's production code they fail; with the change they pass three runs in a row (engine 7, server 8 + 2, chunk 1, orchestrator 6).
• Cases: attempt 1 stalls, attempt 2 on two workers lands its first frame 200 s in, the render completes; every attempt stalls, the render fails typed within about the summed windows; a capture landing a frame every 50 s for 2,200 s is never killed; keepalive during the queue wait, none after a terminal event; a never-settling flush and a never-settling memory sample both give up.
• Sixteen single-line mutations of the production code each turn their test red. Format, lint, both typechecks, comment ratchet, fallow pass.

Not exercised

No real browser render. verify:packed-manifests needs every package built (size measured on the producer pack directly). A pool that lands no frame in 300 s now fails typed instead of taking the single "Network.enable timed out" retry at half the workers.