Step 2: text-to-video through LongCat-Video, single GPU, bf16. The engine exists now;
i2v, continuation/long-video and the avatar variants are the next increment and are
REFUSED with a 400 rather than silently downgraded.

Step 1 missed a prerequisite, fixed here: LongCatVideoPipeline lives in the repo's own
`longcat_video` package, not on PyPI (`from longcat_video.pipeline_longcat_video import
LongCatVideoPipeline`), and it vendors its own Wan VAE and scheduler. So the repo SOURCE
is bundled like Wav2Lip/SadTalker — code only, no weights — and the service prepends it
to sys.path.

- tools/longcat_common.py: the contracts both sides share, stdlib-only so it runs on 3.10
  and 3.13 alike and is loaded BY PATH from each. Checkpoint layout
  (tokenizer/text_encoder/vae/scheduler/dit + lora/*.safetensors), the stage table, the
  presets, and the segment arithmetic — 93 frames per call of which 13 re-render the
  previous tail, so a segment ADDS 80, which is what makes upstream's "11 segments for a
  1-minute video" come out at 59.5 s. Getting that wrong silently truncates long output.
- tools/longcat_service.py: runs IN the 3.10 venv, serves /health /progress /generate
  /unload. Fuses the right LoRA per stage (stages 2 and 3 ARE their LoRAs — the distilled
  pass is 16 steps because of cfg_step_lora), and refuses 'refinement' with no earlier
  frames instead of generating something else.
- codai/api/longcat_worker.py: venv/source resolution, process lifecycle, and VRAM
  registration through acquire_stt_backend so eviction reclaims it by stopping the
  subprocess — the only way to be sure a 13.6B DiT's pages are gone. ensure_built REFUSES
  by default with the exact manual command, because auto_build pulls torch 2.6 plus its
  CUDA runtime; the venv probe asserts 3.10/2.6/4.41 rather than a bare `import torch`,
  since the image rewrites pyvenv.cfg and a mis-pointed venv would import the main venv's
  torch 2.11. service_key includes config_id/variant: sibling configs on one path are
  DIFFERENT residencies and must not share a service or a measured footprint.
- Detection honours the backend pin, then alias/served-name/path. The dispatch branch in
  video.py unwraps `_raw_cfg` first, because build_runtime_kwargs emits a FIXED key list
  for video models with no backend, alias or path in it — which is exactly why H3's
  documented `backend: "h3"` switch is dead. Not inherited.
- The worker path reports progress and is cancellable: the service exposes /progress and
  the engine polls it onto the existing bar. H3's worker path has neither.
- VideoGenerationRequest gains `quality` (draft|fast|best) and `stage`
  (base|distill|refinement), the preset and resumable-per-stage halves of the staging
  requirement.

31 tests. NOT covered, and so not claimed: a real generation — that needs the venv, the
repo checkout and the ~83 GB checkpoint.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0182DhR1eFNPQyGmDrpHbedY