[ref-watch-phosphene-live-video-stage] Put forming renders on the main stage

[atomantic]

From reference-watch review of Phosphene (commits e0a5efca, ee16a684, 3f80c5af, 61e8c5fb, 2026-08-19).

These commits turn an in-flight local video render into a guarded, full-size main-stage preview, retain an animated loop when available, fall back to still frames, and use the job's resolved dimensions for portrait/landscape rendering. PortOS already has stepwise image previews and socket/SSE video progress, but VideoGen currently waits for the completed MP4 before offering a gallery preview; adding this would materially shorten feedback time for LTX/H3 renders without stealing a clip the user is actively watching.

Fix: Extend scripts/generate_ltx2.py#run_text()/run_image() and the H3 helpers (scripts/generate_minimax_h3.py#main(), scripts/generate_minimax_h3_cuda.py#main()) to publish bounded, job-scoped preview frames; update server/services/videoGen/local.js#generateVideo() and server/services/videoGen/events.js#videoGenEvents to forward an explicit preview contract; add a client/src/components/videoGen/LiveVideoStage.jsx (or equivalent) and wire client/src/pages/VideoGen.jsx to show live frames with safe hold/return behavior and the render's width/height aspect ratio. Cover preview cleanup, stale-job isolation, portrait geometry, animated-loop fallback, and completion handoff in the corresponding server/client tests.

Estimated scope: large.

[atomantic]

Partially shipped in #4712 — the PortOS-owned half of this issue.

Landed: a LiveVideoStage on VideoGen showing the forming render at its resolved geometry (live runner frame → the extend source clip as an animated loop → the conditioning still → the finished clip), with guarded hold/return so it never swaps a clip out from under the user. Plus the two wire gaps that would have made a runner-side preview unreachable anyway: useMediaJobSse silently dropped the queue's preview frame, and the render's resolved geometry (both edges snapped to the model's resolution grid) never reached an SSE client at all.

Left open here: the runner-side stepwise preview named in the Fix section. None of the three pipelines exposes a step callback — generate_and_save takes none, and generate_minimax_h3_cuda.py documents that a ModularPipeline rejects callback_on_step_end — so it means monkey-patching the vendored denoise loop and paying a VAE decode per preview step. That cannot be validated without a multi-minute GPU render, and it risks both render throughput and pin fragility, so it was deliberately not attempted blind.

Concretely, what remains:

• --preview-dir plumbing and a bounded, job-scoped frame publisher in server/services/videoGen/local.js, mirroring imageGen/local.js's stepwiseDir watcher (mtime ordering, read latch, cleanup on every terminal path, stale-job isolation).
• The per-runner step hooks: for LTX-2 a patch of the denoise loop resolved the way _install_guided_denoise_teacache_patches() already resolves its target module across pins; for MiniMax H3 a hook around the existing ProgressWriter scrape. scripts/_runner_common.py#make_stepwise_callback is the starting point but decodes a 4-D image latent — video latents are 5-D (B,C,T,H,W) and need a frame-selection projection.
• Benchmark the added render time before shipping it on by default; a per-step VAE decode on a long render is not free.

Everything downstream is already in place: a runner that starts emitting currentImage for a video job reaches the stage with no further wiring.

[atomantic]

Done ✓ — the stage itself shipped in #4712 (rebase-merged to main): LiveVideoStage on VideoGen at the render's resolved aspect ratio, the dropped preview frame in useMediaJobSse reconnected, and a render-meta frame carrying the model-grid-snapped geometry (persisted on the job and replayed to each attaching SSE client, including chunked renders).

Remaining ▢ — the runner-side stepwise preview. None of the three pipelines exposes a step callback today (generate_and_save takes none; the CUDA helper documents that a ModularPipeline rejects callback_on_step_end), so it means patching the vendored denoise loop plus a VAE decode per preview step — not verifiable without a multi-minute GPU render. Releasing the claim so this is re-pickable.