The built-in deepseek cast dialed a model DeepSeek retired

[tobert]

Setting the DeepSeek backend up on this box surfaced a shipped default that cannot work. The provider's catalog serves deepseek-flash and deepseek-v4-pro. There is no deepseek-v4-flash — and that is what default_models seeds the built-in deepseek cast with. Install kaibo, declare a DeepSeek key, ask for cast="deepseek", and the call fails at request time on a default we ship.

Both roles now name deepseek-flash. The undated id is the rot-resistant one — it tracks each new flash generation rather than pinning a version the provider will retire under us — and DeepSeek is folding v4-pro into flash, so the two-tier split has nothing left to split.

The same dead id was in four documents: docs/config.md twice (including the built-in registry table), docs/config.example.toml three times (one of them the annotated slot example an operator copies), docs/casts.md, and README.md (the built-in table and a sample provenance footer). Two of those are include_str!'d and served as kaibo://config/guide and kaibo://config/example, so an operator or a model reading them was being taught a config that cannot work.

Why it drifted: nothing tied the registry to the documents. the_guide_names_the_models_every_built_in_cast_dials now does — for every built-in cast, the embedded guide must name both models it dials. Run against the old pair it fails and names the id, which is the check that would have caught this the day DeepSeek changed the catalog.

A correction inside this PR

I first reported credentials::load() as dead code and was going to delete it with key_file() and key_file_name(). It is not dead — live_key in tests/consult.rs:1791 calls it as the fallback an #[ignore]d live probe uses when the operator's config declares no backend of that kind. My grep covered src/ only and the caller is a bare load(kind) in tests/.

What is wrong there is prose, and it is what misled me: credentials.rs opened by saying a per-provider dotfile in $HOME is the source of truth with the env var winning over it. That describes seeding kaibo removed. The same module doc says so correctly four paragraphs down, and docs/config.md has documented the removal all along — the docs were right, the module doc contradicted itself. It now leads with what is true (kaibo resolves declared sources only, and these names are what an operator points api_key_file/api_key_env at) and scopes load() as live-probe infrastructure.

Suite 1363/0, clippy clean.

🤖 Generated with Claude Code