feat(resilience): expose providerQuotaOverrides via /api/resilience

[herjarsa]

Problem

\providerQuotaOverrides\ (per-provider RPM/concurrency overrides, #6846 Phase 1) can only be applied at startup via \initializeRateLimits()\ and cannot be configured through any REST API:

• \PATCH /api/resilience\ uses \updateResilienceSchema\ (strict) which does not accept the field — operators must edit the DB directly and restart the process.
• \syncRuntimeSettings()\ only re-applies
  equestQueue\ on the hot path, so even a future schema fix would not take effect until restart.

Solution

Expose the existing override mechanism through /api/resilience:

1. Schema (\src/shared/validation/schemas/settings.ts): \updateResilienceSchema\ now accepts \providerQuotaOverrides: Record<providerId, { rpm?, concurrency? }>\ (int >= 1, strict entries), and a body containing only overrides passes the \superRefine\ emptiness check.
2. Hot reload (\src/app/api/resilience/route.ts): \syncRuntimeSettings()\ now calls \setProviderQuotaOverrides(resilienceSettings.providerQuotaOverrides)\ alongside \�pplyRequestQueueSettings(), mirroring \initializeRateLimits()\ — a PATCH takes effect without a process restart.
3. Visibility: both \GET\ and \PATCH\ responses expose \providerQuotaOverrides.

Tests

New \ ests/unit/resilience-settings-provider-quota-overrides.test.ts\ (11 cases): schema accept/reject (incl. lone-override body and strict-entry rejection), merge/normalize behavior, resolve round-trip, and route wiring (GET/PATCH response fields + hot-reload call). All pass; existing resilience suites (24 tests incl.
esilience-tab-response-fields) remain green.

Notes

While verifying the hot path I found the docstring on \setProviderQuotaOverrides\ (\open-sse/services/providerDefaultRateLimit.ts) is stale: it claims the function is called by \initializeRateLimitProtection()\ and \�pplyRequestQueueSettings()\ — the real caller is \initializeRateLimits(), and \�pplyRequestQueueSettings()\ does not call it. The docstring is left untouched in this PR (comment-only fix could follow separately).

[diegosouzapw]

Thanks for the PR. Please address the mandatory items (tests and/or merge blockers) in this branch, then rerun checks before /merge-prs.

[diegosouzapw]

Thanks for the PR. Please address the mandatory items (tests and/or merge blockers) in this branch, then rerun checks before /merge-prs.

[diegosouzapw]

Thanks for the PR. Please address the mandatory items (tests and/or merge blockers) in this branch, then rerun checks before /merge-prs.

[diegosouzapw]

Thanks for the PR. Please address the mandatory items (tests and/or merge blockers) in this branch, then rerun checks before /merge-prs.

[diegosouzapw]

Obrigado pelo PR. Mantive a revisão de fix-in-place e não foi possível concluir o ajuste completo aqui:

• Para os PRs em fork: não consigo aplicar push de correção diretamente na sua branch.
  Por favor, faça um rebase/sync com release/v3.8.50, resolva conflitos se houver, e rode os checks dessa branch.
  Se preferir, posso aplicar a correção na próxima rodada assim que você mandar o branch atualizado ou confirmar que o PR está limpo pra esse merge.

[herjarsa]

Synced with the current release/v3.8.50 tip — merged the 15 new base commits into feat/provider-quota-override-api (no conflicts; fast-forward pushed).

Verified in the merged tree:

• tests/unit/resilience-settings-provider-quota-overrides.test.ts + resilience-tab-response-fields → 13/13 pass
• npm run typecheck:core → clean

⚠️ base-red inherited: the unit jobs will still fail on i18n-vi-completeness / radar-* until the Vietnamese-locale drift from #9697 is fixed on the base — the fix is in flight on #9816 (i18n(vi): complete Vietnamese locale key parity). Nothing in this PR's diff touches i18n.