Two bugs of the same shape: a signal that already existed and was not consulted.

Same-path siblings. Two cards can share one weights path and differ only in
settings -- Wan2.2-I2V-A14B-Lightning and the plain Wan2.2-I2V-A14B both point
at Wan-AI/Wan2.2-I2V-A14B-Diffusers, declaring 22 GB and 151 GB. The manager
has disambiguated exactly this since the lisa/lisa-32k case, through
`requested_id`, and NEITHER placement caller passed it. So the Lightning card
was sized by its 151 GB sibling, read as ~127 GB over free VRAM -- far outside
the borderline band -- and went straight to CPU offload without trying the
card, where it computed at 0% GPU for 26 minutes holding 37 GB of host RAM.
Measured: 97.4 GB without the id, 14.1 GB with it, which is the difference
between exile and residency on a 24 GiB card. Quantizing the experts was
necessary but not sufficient; the ESTIMATE was still the wrong card's.

The leak watcher's load signal. _load_in_progress() consulted only the
manager's ready event, which diffusers image/video loads never touch -- they
load in codai/api/{images,video}.py. A 12-minute multi-shard load therefore
looked idle, its monotonically rising RSS looked exactly like a leak, and the
mitigation ladder ran against a load doing nothing wrong ("RSS 19.8/43.0 GB
LEAK SUSPECTED", every poll). It now also consults the loading reservations,
which cover those paths by construction.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014T3rZozi1Ehk96NG1WesgC