feat: expose an explicit tier override for any provider connection (#7818)

[diegosouzapw]

Summary

Closes the actual gap behind #7818/#7763: classifyTier() (open-sse/services/tierResolver.ts) already honored a DB-backed providerOverrides list keyed by an arbitrary provider-id string — it worked identically for a built-in or custom provider — but nothing exposed that mechanism through any UI or API route, for any provider. This PR is that missing surface.

• New GET/PUT /api/settings/tier-config route: reads/writes a single provider's tier override in the existing tier_config table (loadTierConfig()/saveTierConfig()), validated with a z.enum(["free","cheap","premium"]) schema, and busts the in-process routing cache via setTierConfig() so a change applies immediately.
• New generic tier-override <Select> wired into EditConnectionModal.tsx's Advanced Settings section (ProviderTierField.tsx + providerTierField.ts helpers, mirroring the existing m365Tier.ts pattern in the same directory) — applies uniformly to every connection, built-in or custom, no capability gate.
• TierCoverageWidget.tsx::classifyConnection() now consults the same override before falling back to its existing registry-membership check, so a tiered custom provider shows up in the correct bucket instead of always landing in "Cheap".
• i18n keys added to en.json + pt-BR.json under the providers namespace (tierOverride*).

No database migration — tier_config already exists via migration 059_manifest_routing.sql; verified via grep -rln "loadTierConfig\|saveTierConfig" src/app/api/ returning empty before this PR.

Scope decision (owner-confirmed): the original report says "4 tiers", but the actual ProviderTier machine enum (open-sse/services/tierTypes.ts) has exactly 3 values (free/cheap/premium) — the "4" is README.md marketing copy conflating two separate 3-bucket classifiers. This PR implements the override for the 3 real machine values and does not extend the enum. Nothing else is deferred; the feature is complete against the amended (3-tier) scope, so this closes the issue.

How validated (Hard Rule #18 — TDD, proved red before green)

Added 4 new top-level test files (26 assertions across 14 test cases):

• tests/unit/tier-config-provider-override-route.test.ts — exercises the route's GET/PUT against a real isolated SQLite test DB (DATA_DIR temp dir + resetDbInstance() in beforeEach/after). Covers: set override for a custom (non-registry) provider id, clear via tier: null without touching other providers, reject an invalid tier with 400 (and assert the error body doesn't leak a stack trace), reject an empty provider string, and round-trip cleanly against an already-populated tier_config row (no-migration scenario).
• tests/unit/tier-resolver-provider-override.test.ts — proves the setTierConfig() cache-bust actually matters: calls classifyTier() directly before and after a PUT, asserting the routing side picks up the override on the very next call (using a fresh model key so a stale per-key cache entry can't fake the result).
• tests/unit/tier-coverage-widget-provider-override.test.ts — classifyConnection() unit tests (override-before-registry precedence, case-insensitive lookup, fallback to registry membership).
• tests/unit/provider-tier-field-helpers.test.ts — fetchProviderTierOverride/saveProviderTierOverride/normalizeTierValue against a stubbed global.fetch.

Proved the red (not a placebo): deleted src/app/api/settings/tier-config/ entirely (backed up first, restored after) and re-ran the route + resolver test files — both failed with ERR_MODULE_NOT_FOUND (the route genuinely didn't exist before this PR). Also reverted classifyConnection() to drop the override lookup and re-ran the widget test — it failed with 'tier2' !== 'tier1' / 'tier2' !== 'tier3' assertion errors, proving that test isn't a DOM-less placebo either. Restored both files and reran green afterward.

Gates run (all green)

• node scripts/check/check-test-discovery.mjs
• npm run typecheck:core — clean
• npm run typecheck:noimplicit:core — pre-existing errors only in open-sse/services/combo.ts, open-sse/utils/usageTracking.ts, src/shared/services/cliRuntime.ts (confirmed identical against origin/release/v3.8.49, untouched by this diff)
• npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> — clean
• npm run check:complexity-ratchets — cyclomatic 2076 (baseline 2130), cognitive 901 (baseline 950), both OK
• node scripts/check/check-file-size.mjs — OK; EditConnectionModal.tsx frozen baseline bumped 1286→1288 (net +2 lines: one import + one <ProviderTierField .../> render call, justified in config/quality/file-size-baseline.json's new _rebaseline_2026_07_20_7818_provider_tier_field entry, mirroring the existing m365Tier.ts/AgentRouter precedents)
• npm run check:mutation-test-coverage — no drift (tierResolver.ts/tierConfig.ts/the new route are not in Stryker's mutate set, confirmed before writing tests, so no tap.testFiles registration was needed)
• node scripts/check/check-dashboard-typecheck.mjs — 2 pre-existing failures (AgentEmoji.tsx, GheConfigStep.tsx), confirmed via git diff --stat origin/release/v3.8.49...HEAD to be untouched by this PR
• npm run check:cycles — no new cycles
• New tests run directly — 14/14 pass

npm run test:coverage intentionally not run locally (heaviest gate, shared box) — CI runs it authoritatively.

What was deferred

Nothing from the confirmed (3-tier) scope. The only thing explicitly out of scope is extending ProviderTier to a 4th machine value (subscription vs. API-key), which the plan's Open Question flagged as a materially larger, separately-scoped change — the owner confirmed the 3-value scope for this issue.

Closes #7818

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[diegosouzapw]

Reviewed and verified this against a clean worktree off release/v3.8.49:

• All 4 new test files (15 assertions) pass for real — including the two subtler ones: proving the setTierConfig() cache-bust actually matters (not just that the override array gets persisted), and proving classifyConnection()'s override-before-registry precedence.
• Pre-existing touched-area tests (db-tier-config.test.ts, m365-tier-selector-6334.test.ts — the precedent this PR's ProviderTierField mirrors) still pass, no regressions.
• Targeted ESLint on the 5 changed files is clean.
• Clean merge against current release/v3.8.49, no conflicts, diff is exactly the 13 files / +591/-6 the PR claims — not a bloated branch.
• The CI reds on this PR (Fast Quality Gates, No new ESLint warnings, Unit Tests fast-path 1-4, dast-smoke) are the known base-red TICK_MS is not defined cascade from perf(memory): mitigate event-loop starvation under 3000+ provider connections #7719 — confirmed identical on unrelated open PRs on the same base, unrelated to any file this PR touches.

Good use of the existing providerOverrides mechanism — the backend half was already there and untested through any real surface; this closes that gap cleanly with the right auth/Zod/error-sanitization wiring on the first pass. Merge-ready once CI reflects the release/v3.8.49 base-red fix.

[diegosouzapw]

Validated in local merge-train on tomni-proxmox-113 @ 19bcf534352e24cdd2448cdfdfd64d5bd9695c74 (FAST gates green: static + changed tests + vitest)