perf(models): fix /model picker UI-thread freezes and forced provider-tab re-fetches

[laerad777]

What

Two perf fixes for the /model picker, both reproduced on the bundled catalog (4,276 models / 1,243 canonical records):

1. UI-thread freezes (5182d07e5): selection and every catalog change blocked the main thread ~350–400ms; open-time canonical resolution cost ~700ms more.
2. Forced provider-tab re-fetches (59110d0ed): every provider-tab visit forced a network round-trip, even with a fresh discovery cache.

Root causes

1. Per-record O(catalog) rebuilds. #filterCanonicalVariants rebuilt a 4,276-entry candidate-key Set once per canonical record (1,243× per query — even when zero records survive filtering), #resolveCanonicalVariant rebuilt a provider policy + catalog order per record, and the selector re-resolved every record through the same path again. Landed with the 2026-07-22 presets refactor; only manifests for credentialed users (empty catalogs never reach the hot path), which is why CI fixtures never saw it.

2. Provenance-less discovery cache rows. Configured discovery published rows whose discovered model ids carried no provenance fingerprint; the model-manager treats id-bearing rows without a matching fingerprint as permanently suspect and re-fetches under every network strategy. Combined with the selector being the app's only online-strategy holdout, each tab visit re-fetched unconditionally.

Fixes

• getCanonicalModels builds the variant filter plan once per query; new batch getCanonicalModelSelections resolves every record with one shared candidate set, provider policy, and catalog order. Selector #materializeModels and --list-models consume the batch form. Per-record resolveCanonicalModel semantics unchanged.
• Selector tab refresh uses the app-wide default strategy (online-if-uncached); configured discovery publishes the same credential-evidence+endpoint fingerprint the built-in descriptor path already records; cache-served revisits now report the cache row's real fetchedAt instead of Date.now().

Numbers (M5 Pro, bundled catalog)

Path	Before	After
getCanonicalModels(candidates)	348ms	1.5ms
Batch canonical resolution	~700ms	7.5ms
Post-selection refresh	397ms	13.6ms
Per-catalog-change refresh	407ms	12ms
Provider-tab revisit (fresh cache)	network round-trip	0 fetches (incl. cross-process)

Freshness gates survive and are test-pinned: 24h TTL expiry, credential change, and endpoint change each force a re-fetch; a zero-fetch revisit test pins the new positive behavior.

Verification

• 276 tests pass (model-registry incl. 3 new equivalence/pin tests, discovery-manager); typecheck clean; PTY dogfood on both builds with a real OCX config showed functional parity, zero errors
• Whole-catalog equivalence tests: batch ≡ per-record loop across availableOnly × candidate-subset × whitespace-sessionId scenarios
• Independent review: architect + critic passes on both commits (ship / approve; all findings addressed — sessionId trim parity, matrix breadth, fetchedAt honesty, changelog accuracy)

Known tradeoffs (documented in CHANGELOG)

• Provider tabs reflect server-side catalog changes at most once per 24h unless credentials/endpoint change; /model <selector> miss still forces a live probe
• /model has no explicit force-refresh keybinding (follow-up)
• OAuth token rotation invalidates the discovery cache (pre-existing identity design; safe over-fetch direction)

GJC verdict

gajae.pr-review-verdict.v1 needs-human sha256:b64a204bf6c0a53d8822bd92fc20ab63e2bf3c8af488639f785396c015e2d0d7 reviewer:human reviewer-id:laerad777 evidence:local suites 305 pass on b6977432a (model-registry + role-badge); prior head CI test shards green

---

• Target branch is dev
• bun check passes (coding-agent package: types + biome clean; full-suite single-process OOMs locally, CI shards green)
• Tested locally
• CHANGELOG updated
• Verdict above matches the exact PR head (b6977432a), not an earlier commit

[Yeachan-Heo]

CI triage for the model-selector failures on the first run of this head (95211100724):

• model-selector-role-badge-thinking.test.ts → 1 fail: "refreshes Ollama Cloud using provider id instead of tab label" — expected knownProviderIds without "online-if-uncached", received one extra entry (line 518). This looks directly related to this PR's provider-tab re-fetch changes (model-selector.ts is in the diff), not a flake: the refresh path now surfaces the online-if-uncached pseudo-provider id into the canonical list.
• The other 11 failed jobs are downstream aggregates (evidence producer / ts-build fan-out) of that single test-file failure; the sibling run on the same head already passed everything else.

Local baseline check: dev head c83ffe3 passes 30/30 on that file, so the delta is introduced by this branch. Suggest either filtering online-if-uncached out of knownProviderIds in the refresh path or updating the pinned expectation if the new id is intentional.

—
[repo owner's gaebal-gajae (clawdbot) 🦞]

[laerad777]

Force-pushed: previous heads accidentally carried an unrelated local-only commit (43bf5e9ce, packages/agent work) because the branch was rebased onto an unpushed local dev tip. New head b6977432a contains exactly the three perf/test commits against origin/dev (c83ffe3d7); PR diff is now coding-agent-only (18 files).

• CI test failures from the first run are fixed (spy arity + hermeticity/timeout of the equivalence scenarios — seeded credentials, split tests, winner-semantic assertions).
• Verdict: needs-human per template (no authenticated approving review for this head; author has no write access). Happy to address any review feedback.