legacy empty-provider openai-adapter keys stay route-dependent on unset api_base after #1017

Residue acknowledged during the #1018 audit.

resolve_base_url's openai default-base fallback (#1017 / #1018) is keyed strictly on provider == "openai". The openai family bridge is looser: it refuses only a non-empty non-openai vendor and still falls back for the legacy empty-provider shape (family_bridge_allows_legacy_empty_provider_with_empty_api_base).

So a legacy row {provider: "", adapter: "openai"} with no api_base remains route-dependent — chat falls back to the default base via the bridge, while the direct-HTTP routes (audio, image edits, jobs, realtime, responses, count_tokens/messages) 400 — the same symptom class #1017 fixed for well-formed rows.

The resolver's strictness is deliberate: it also serves non-OpenAI-family paths (an empty-vendor anthropic-adapter row must never fall back to api.openai.com), so the empty shape cannot be widened there without an adapter-aware check. Options, in rough preference order:

1. Close the legacy shape at the source: have the loaders / cp-api reject or migrate empty-provider rows (provider is written on every row by cp-api today; only hand-written declarative files can produce the shape).
2. Adapter-aware fallback: allow the empty-vendor fallback only when adapter == openai, mirroring the bridge's exact predicate — needs a sweep of the anthropic-family callers to prove no path can reach it with a non-OpenAI credential.
3. Tighten the bridge instead: make the family bridge refuse the empty shape too, converging on strict — a behavior change for any legacy rows still relying on it, so it needs the compat treatment.

Either way, the two predicates (bridge vs resolver) should end up documented against each other; today the divergence is only stated in resolve_base_url's doc comment.

Start with the resolve_base_url fallback and family_bridge_allows_legacy_empty_provider_with_empty_api_base predicate, then trace the loaders/cp-api and the listed direct-HTTP routes. Decide which compatibility option is intended, verify the bridge and resolver predicates no longer diverge unexpectedly, and document their relationship.