…ider fallback

Resolves Martian-Engineering#251. When a user declares `models.providers.<p>.models[*].api` in
runtime config, that declaration should win over the hardcoded
`inferApiFromProvider()` map.

Concrete repro: setting `summaryModel: "openai-codex/gpt-5.4-mini"` against the
paid OpenAI API endpoint (where the `openai-codex` provider is configured with
`baseUrl: https://api.openai.com/v1` and the model declares
`api: "openai-completions"`) was failing every compaction call with
`error_message=Not Found`. The dispatch-site fallback chain at
`src/plugin/index.ts:1535-1556` couldn't see the user-declared api because:
  - `mod.getModel(provider, model)` returned a model object without `.api`
  - `resolveProviderApiFromRuntimeConfig` only looked at provider-level `api`
  - The first-models-list fallback hit a different model
So the chain bottomed out at `inferApiFromProvider("openai-codex")` →
`"openai-codex-responses"`, sending Codex Responses-shaped requests to
api.openai.com which doesn't speak that protocol.

Fix: add `resolveModelApiFromRuntimeConfig(config, provider, model)` that walks
`models.providers.<p>.models[]` and returns the matching model's `api` if
declared. Slot it into the dispatch chain right after the provider-level
runtime resolver and before the first-models-list and `inferApiFromProvider`
fallbacks.

Behavior is purely additive: users who don't declare `models[].api` see no
change, and `inferApiFromProvider`'s existing semantics for Codex CLI auth
users (no explicit api) are preserved.

- Adds: `resolveModelApiFromRuntimeConfig` (exported for testability)
- Tests: 7 new cases covering happy path, case-insensitive provider match,
  multi-provider disambiguation, missing/malformed config, missing api field
- All 782 tests pass (43 + 1 new file, 775 + 7 new cases)
- Build clean (esbuild → 624kb)