fix(capabilities): honor model-compat vision overrides in catalog and combos

[xiaoyaner0201]

Summary

Make the canonical vision-capability resolver consume the existing per-model compatibility override that runtime routing already honors. This is the override-wiring slice of #14587; per-member combo diagnostics remain out of scope and the issue should stay open for them.

Refs #14587. Builds on, but does not replace, #14642.

Behavior

• Preserve explicit precedence: Custom Models boolean > model-compat boolean > synced/registry/spec/heuristic sources. An explicit false stays authoritative.
• Resolve compat values within the appropriate provider/alias/no-auth sibling namespace, including own-provider-prefixed object inputs; unrelated providers' identical bare IDs are not searched.
• Bulk-load the compat override map once per capability snapshot. Model catalog and all three combo-list projections reuse a collection snapshot rather than adding a query per member.
• No persistence migration, new API payload, dependency, MiMo heuristic change, or member-diagnostic UI.
• Remove two obsolete unused-import suppression entries and register the regression test for mutation coverage; no baseline is widened.

Relationship to our earlier #14642

#14642 fixed own-provider prefix normalization for the already-supported Custom Models source. It did not introduce the compat-source omission.

We compared the exact modelCapabilities.ts from #14642's parent cbb2ebef0de2473f888c61950c91b9714e93ece7 and its merge e7738bda3ccef180a0814a64da68d9c6727f3cd2, using a shared dependency environment and fresh temporary SQLite fixtures. The parent source was reconstructed from the exact patch and its Git blob matched the real parent tree entry.

• Custom Models, bare id: true before and after.
• Custom Models, prefixed object id: null before, true after.
• Compat override, bare or prefixed id: null before and after, while runtime getModelInfo reads the same compat override as true.

This is a source-isolated A/B, not a replay of an entire historical deployment. It establishes the omitted read source predates #14642. That prefix fix now also helps the new compat lookup resolve prefixed combo inputs.

Verification

Candidate tested against release/v3.8.52 at 666ea59b4c5980062c4012ee9228135ee4dd8989.

• Original-behavior RED: five assertion failures with the runtime control passing. Isolated sabotage of the new compat-priority branch fails the expected null !== true assertion.
• Parent post-refresh focused regression: 63/63 pass, including the original fix(capabilities): honor Custom Models vision flag for prefixed combo steps (cx/<id>) #14642 regression, canonical true/false/unset/alias/provider-isolation cases, bulk snapshot, catalog and combo projections.
• Parent re-ran the historical source A/B and independently verified both source blob hashes.
• Core, API and Open-SSE typecheck gates pass.
• Changed-file ESLint/Prettier, file-size, complexity/cognitive, dead-code and TS7 diagnostic ratchets pass.
• npm run build:contributor passes (backend/API compilation, not a full release/package build).
• Fresh independent read-only review of the exact candidate returned PASS with no blocker.

Existing base failures / scope limits

• typecheck:noimplicit:core: the same autoStrategy.ts:519 TS7006 on candidate and exact base.
• Strict mutation-registration gate: identical 24 unrelated omissions on both trees; this PR's regression is registered and adds none.
• No full unit-suite or CI-green claim; focused runs exclude host-affecting CLI serve/stop tests. CI status is separate.
• No production deployment or live provider request was used.

Tests added

tests/unit/model-compat-vision-canonical-resolution-14587.test.ts

Concurrent PRs

Trial-merge against #15087 succeeds, including the independent Stryker registrations. The only shared path with the existing Team/cost-center PR #10409 is config/quality/eslint-suppressions.json. Its old public head already conflicts with the current base; the trial merge with this PR reports exactly the same conflict-path set as the base-only control. #10409 should reconcile that suppression file when refreshing onto the current cycle; this PR does not depend on it.

[xiaoyaner0201]

CI documentation-gate attribution on the current head and exact release/v3.8.52 base 666ea59b4c5980062c4012ee9228135ee4dd8989:

npm run check:docs-counts exits 1 on both, with the same two strict findings: README.md still says OmniRoute v3.8.51, and llm.txt still says Current version: 3.8.51, while package.json is 3.8.52. I ran the identical command on this candidate and a pristine exact-base checkout and compared the diagnostic lists. Neither document nor the version bump is changed by this PR.

This is the new-cycle base's documentation drift, not a candidate-owned regression. I have not edited instruction surfaces or loosened the gate to make this branch green. Other CI jobs are tracked separately; this is not a full CI-green claim.

[diegosouzapw]

Thanks @xiaoyaner0201 — merged into release/v3.8.52; it ships in the next release.