cards: a loaded registry snapshot hides bundled card additions entirely (no per-id fallback)

[ttupper92618]

What happened

A new bundled model card added on a dev branch (mlx-community/Ministral-8B-Instruct-2410-4bit, added for the Mistral tool-dialect lane) is invisible on any node whose signed-registry snapshot loads: GET /instance/previews answers Unknown model ... add it through POST /models/add before use, and the harness's POST /models/add recovery is itself refused off-loopback (This operator mutation is available only through loopback). Only disabling the registry (SKULK_MODEL_REGISTRY_ENABLED=false) or a registry outage makes the bundled card reachable.

Why it matters

The snapshot wholesale replaces the catalog rather than layering over the bundle, so a bundled card for a model id the registry has never heard of is dead code on every registry-connected fleet. Shipping a new model card in the repo therefore does nothing for dev-channel users until a registry publish independently carries it — the same coupling that keeps the #878 tool-truth corrections inert, but for card additions rather than corrections, where "registry knows better than the bundle" cannot be the intended semantics: the registry has no opinion on an id it has never seen.

Suggested direction

Fall back per model id: resolve from the snapshot when it carries the id, from the bundle when it does not. That keeps the registry authoritative wherever it has an opinion while letting the repo ship cards for new models. (Distinct from #890, which is about the installed-card record freezing truth for already-downloaded artifacts, and from #878, which is about the snapshot's card content.)

Found on dev during the Mistral tool-dialect validation arc.

🤖 Generated with Claude Code

[ttupper92618]

Reframing after PR #896 was withdrawn in review: a client-side per-id merge is NOT implementable safely, because snapshot absence is the shipped revocation mechanism for once-bundled cards (test_successful_refresh_excludes_unlisted_bundled_cards), and the client cannot distinguish a revoked id from a bundled addition the registry has never seen. Resurrecting revoked aliases is a trust-plane regression, so the convenience loses.

What a real fix needs, on the registry side: either explicit tombstones in the signed catalog (absence stays ambiguous, removal becomes a statement) or a signed ever-seen id set the client can subtract. Until then:

• Interim path for new models on registry-connected fleets: the custom-card override directory (~/.local/share/skulk/custom_model_cards/), which loads last, survives snapshots by design, and carries operator intent explicitly.
• Two review notes recorded for the eventual implementation: the bundled pass must be memory-cached (the per-minute registry refresh must not re-parse the full bundle from disk), and the refresh test must monkeypatch every module global it touches.

This issue therefore joins #878 and #890 as the third leg of the catalog-propagation design pass, rather than a standalone code fix.

🤖 Generated with Claude Code

[ttupper92618]

Design drafted: foxlight-docs initiatives/model-card-registry/catalog-truth-layering.md. Summary: the signed snapshot gains an explicit revoked_ids tombstone list; resolution is snapshot card wins, tombstoned id is absent even when bundled, and any other bundled id is visible, so absence stops meaning suppressed while revocation stays a deliberate signed act (the #896 withdrawal's constraint). A snapshot without the field keeps today's wholesale semantics, so nothing changes until a new-format snapshot is published. Implementation is gated on the reviewer freeze lifting and the snapshot-format sign-off.