demo: resume a part-watched clip, and cap the live canvas width

[ymingxie]

Two independent demo fixes, one commit each.

demo: resume a part-watched clip instead of restarting it

Stopping half way and pressing Start again restarted the run at frame 0 while still
conditioning on the frame left on screen. The picture continued but the bookkeeping did not:
numbering went back to 0, the saved clip was dropped, the force timeline was reset, and every
Start was granted another full frame budget — so the clip-length cap could be walked past
indefinitely by stopping and starting.

Frames 0..N-1 are now the budget for the whole clip:

stopped part-way	resume from the frame the viewer was on, carrying the numbering, the saved clip and the force timeline, and ending at the clip's last frame
watched to the end	new clip from frame 0, conditioned on the upload

Two details that are easy to get wrong:

• The resume base is the displayed frame, not the generator's counter. Generation runs
  ahead of playback, so on Stop the server holds frames the browser never showed. Those are
  dropped from the saved clip — otherwise a save replays them and then jumps back to the seam.
• Force-change landing frames are offset by the segment start. The pipeline numbers latents
  from 0 on every call while the browser reports absolute frame indices; without the offset a
  resumed segment reported changes landing behind the viewer.

Verification

Driven by a headless viewer that paints on a fixed 16 fps clock and reports client_stats the
way the browser does, against a 0..176 clip:

stop at frame 81  -> Start  =>  frames 82..176   (resumes, and stops at the cap)
watch to 176      -> Start  =>  frames 0..       (new clip)

Server log at the seam: [gen] continuing from frame 82 (viewer was on 81); 82 frames kept for saving.

demo: cap the live canvas width instead of filling the column

The canvas was width: 100% of the fluid right column, so on a 1080p screen it upscaled the
832x480 frames to ~1500px (1.8x). Capped at 1248px (1.5x native). Display only — generation
resolution still comes from --height / --width.

---

Not in this PR: the ~6 frames (0.4 s) force-change latency figure in the top-level README did
not reproduce here (measured 13–21 frames / 0.8–1.3 s, warm, at the shipped pacing defaults),
but that measurement is sensitive to the viewer's buffering and was made with a harness that
does not decode JPEG, so the README is left alone pending a real-browser check.

🤖 Generated with Claude Code