feat(mlx): support CorridorKeyBlue on the MLX backend (Apple Silicon)

Context

PR #241 added a dedicated blue-screen checkpoint (CorridorKeyBlue) to the Torch backend. The MLX backend on Apple Silicon does not yet have a blue checkpoint, and the project's MLX wrapper repo (nikopueringer/corridorkey-mlx) only ships the green weights at v1.0.0.

For now, this combination fails fast with an actionable error:

# CorridorKeyModule/backend.py — _discover_checkpoint(MLX_EXT, screen_color="blue")
raise RuntimeError(
    "Blue-screen support is not yet available on the MLX backend. "
    "Use --backend torch with --screen-color blue, or wait for the MLX blue release."
)

Mac users who try --screen-color blue see this message and fall back to Torch (or wait). The keyer is otherwise fully functional on MLX for green plates.

Why this is a tracker issue, not a coding task

There is genuinely nothing to write until the upstream artifact exists:

1. The MLX engine (nikopueringer/corridorkey-mlx) consumes a single .safetensors file at runtime — same architecture as Torch but with MLX-specific weight layout.
2. There is no public release of an MLX-compiled blue checkpoint yet.
3. We can't trial-balloon a fix without a test fixture; the whole point of the MLX path is the converted weight format.

Once the blue MLX weight ships (typically as a new GitHub release on the corridorkey-mlx repo), the implementation is small and mechanical — see Approach below.

Definition of done

• uv run corridorkey run-inference --backend mlx --screen-color blue succeeds on a clean Apple Silicon install:
  • Downloads corridorkey_blue_mlx.safetensors (or whatever the published filename ends up being) into CorridorKeyModule/checkpoints/ if absent.
  • Loads it via the same CorridorKeyMLXEngine path used today for green.
  • Despill is applied to the blue channel — see #241 for the channel-routing contract that the existing Torch path already exercises.
• uv run corridorkey run-inference --backend mlx --screen-color auto correctly auto-detects blue plates and routes to the blue weight.
• Existing green-MLX users keep working with no change to their install.

Approach (when the weight ships)

Roughly four edits in CorridorKeyModule/backend.py:

1. Constants (next to lines ~62–64 today):

 MLX_MODEL_URL_BLUE = "https://github.com/nikopueringer/corridorkey-mlx/releases/download/<TAG>/corridorkey_blue_mlx.safetensors"
 MLX_MODEL_FILENAME_BLUE = "corridorkey_blue_mlx.safetensors"

The exact tag/filename comes from whatever corridorkey-mlx publishes.

1. _auto_detect_backend (lines ~67–117): the existing function only knows about the green MLX file. Either: (a) widen it to keep working as long as either MLX file exists, or (b) leave it green-only and let _discover_checkpoint handle the blue download lazily on first use. (b) is simpler and matches the Torch lazy-download pattern.

2. _discover_checkpoint(MLX_EXT, screen_color="blue"): replace the current raise RuntimeError block (lines ~296–300) with the same shape as the green MLX path — _filter_by_color + a new _ensure_mlx_checkpoint(screen_color="blue") helper that downloads from the GitHub release URL via urllib.request.urlretrieve (mirroring the existing green MLX download).

3. _MLXEngineAdapter.process_frame: today the despill in _wrap_mlx_output is hard-coded to channel 1. With a real blue weight the adapter must route screen_channel into despill — replace the if screen_channel != 1: raise NotImplementedError guard with the actual routing. The Torch path's pattern is the model:

 fg_despilled = cu.despill_opencv(fg, limit_mode="average", strength=despill_strength, screen_channel=screen_channel)

1. Tests: add one mock-based test in tests/test_backend.py mirroring test_blue_with_only_green_present_triggers_download (which already exists for Torch) — assert _discover_checkpoint(MLX_EXT, screen_color="blue") calls the right release URL and copies the result into checkpoints/. Also: drop the existing test_mlx_blue_raises — it'll start failing once we land this and we want it to.

Tracking

Watch nikopueringer/corridorkey-mlx releases for a blue artifact. When one lands, this issue can be picked up — the work is contained to backend.py and a couple of tests, probably under 100 lines of net change.