fix(modelsdev): skip models.dev fetch for custom providers (#3165)

[Sayt-0]

Problem

A custom provider — a name that is not a built-in/alias (e.g. mistral_gateway) defined with base_url + token_key — triggered a blocking GET https://models.dev/api.json (full ~3.4 MB catalog) during model resolution. In internet-restricted environments this hangs ~30s on every turn, making a self-contained custom-provider config unusable. Renaming to a known provider (e.g. openai) bypassed it.

Closes #3165.

Fix

modelsdev.Store gains WithKnownProvider: a provider the predicate rejects is served cache-only and never fetches (missing cache → empty catalog → clean "provider not found"). The runtime's default store (lazyModelStore) and RuntimeConfig.ModelsDevStore() are wired with provider.IsKnownProvider, so only catalog providers (built-ins + aliases) can reach the network.

Path	Before	After
loop.go GetModel (every turn)	fetch catalog for any provider	custom → no fetch
session_compaction.go resolveContextLimit	~30s hang air-gapped	resolves instantly
known provider (openai/anthropic/bedrock…)	fetch	unchanged

Verification

Real binary, cold cache, custom-provider config from the issue:

Binary	models.dev catalog fetched
origin/main	yes (~3.4 MB download)
this PR	no

• TestLazyModelStore_GatesCustomProvider (runtime) reproduces the exact issue error without the fix, passes with it.
• modelsdev gate unit tests; go build / vet / golangci-lint / -race green.

Known limitations (follow-ups, out of scope)

• TUI model picker / models CLI still fetch the full catalog (not the request-loop path).
• A custom provider without provider_opts.context_size has no context limit, so compaction stays disabled for it (inference unaffected — it routes via base_url).

[docker-agent]

Assessment: 🟢 APPROVE

The fix is well-scoped, correct, and thoroughly tested.

What the PR does: Adds a WithKnownProvider predicate to modelsdev.Store so that custom (non-catalog) providers are served from cache only and never trigger an outbound GET models.dev/api.json. The lazyModelStore and RuntimeConfig.ModelsDevStore() are both wired with provider.IsKnownProvider.

Correctness review:

• The mutex protocol is sound: getDatabase is called while holding s.mu only from within GetDatabase/getProvider, both of which acquire the lock before calling into getDatabase. No re-entrant locking issue.
• The allowFetch=false path deliberately skips memoization of s.db to avoid poisoning future fetch-eligible lookups for known providers — this is correct and clearly commented.
• NewDatabaseStore leaves knownProvider nil (fetch-eligible for all providers), which is intentional: it is used in tests with an in-memory database, not a live fetch path.
• The loadDatabase stale-cache logic change (!allowFetch || time.Since(...) < refreshInterval) correctly short-circuits on the first err == nil check when fetching is disallowed, so the secondary if !allowFetch block only handles the cache-miss case — logically consistent.
• GetDatabase (public API) always passes allowFetch=true, preserving backward compatibility for direct callers (e.g., TUI model picker, models CLI) that explicitly want the full catalog.
• WithKnownProvider(nil) stores nil, which is handled correctly: s.knownProvider == nil → allowFetch = true (same as no predicate).

Tests: TestKnownProviderGatesFetch, TestNoPredicateAlwaysAllowsFetch, and TestLazyModelStore_GatesCustomProvider together cover the regression, backward compatibility, and production store path. The use of an already-expired context deadline as a stand-in for "network unreachable" is a clean, deterministic approach.

No issues found in the changed code.