Plan item I, the last of the LongCat work.

The tool chains clips because the server generates one clip per request and VACE
frame-tail conditioning is the only continuation a Wan model has. That machinery exists
to fight drift — the dual-expert and VACE-extension notes are both about chained parts
going wrong — and every join is a re-encode.

LongCat was pretrained on continuation, so:

- the client-side split is LIFTED for it (_chunk_max becomes unbounded): a clip's whole
  frame budget goes in ONE request and the server runs the segment loop. Chaining it from
  here would reintroduce exactly the drift the chaining was invented to avoid. Wan/VACE
  keeps the cap it always had;
- between DELIBERATE shots the tool still chains, because a cut is a cut — but LongCat is
  tail-capable too, so it takes the same cond_frames handover. What differs is underneath,
  not the call;
- the tail length follows the model: 13 of 93 frames, which is what LongCat's continuation
  pretraining used, against VACE's 5. Handing it 5 would condition it on less than it
  expects. The constant is asserted against tools/longcat_common.py so the two cannot
  drift apart;
- the log says which continuation produced a shot, because diagnosing a seam starts
  there.

Server side, so a client asks for the frames it wants rather than reimplementing the
loop: num_frames is the PER-CALL count, and a request for more than one call's worth now
derives total_frames and lets the segment loop cover it. An explicit num_segments or
duration_seconds still wins. Passing 400 straight through would have asked the pipeline
for a 400-frame single call.

The uploader and the odds generation are untouched — they are downstream of the frames.

17 tests. No match has been rendered with it: that needs the weights.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY