The keyframe bridge dispatched its nested image request back through the front
via execute_api_request. That deadlocks: by the time the engine handler runs, the
front's GPU-swap gate has already made the VIDEO model the GPU owner for this
request, so the nested request for a different (image) model queues behind the
very request that is blocked waiting for it. Observed on a real Wan run:

  [gpu-swap] queued 'stabilityai/stable-diffusion-xl-base-1.0'
             behind owner 'wan-ai/wan2.2-i2v-a14b-diffusers'

with the GPU sitting at 0% until the request was killed.

Call codai.api.images.create_image_generation directly instead. The engine
already holds the GPU for this request, and its own model manager handles the
load/evict — which is also what we want, since the keyframe must be rendered
before the video weights land.

Verified end to end on real hardware (Wan2.2-I2V-A14B, 4-bit, model-CPU-offload):
t2v request + character_profiles -> "rendering IP-Adapter keyframe" ->
"IP-Adapter loaded" + 72 modules aligned to bf16 -> keyframe in 10 steps ->
"running ti2v from it" -> Wan loaded (24.45 GB VRAM measured) -> HTTP 200 in
1642s with a real 480x480 h264 video, 17 frames, 2.125s, motion present between
first and last frame.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01R6iugoNeEgt9PkajKrFyq4