fix(providers): don't silently enable rate-limit protection on PATCH unless persisted

[diegosouzapw]

Summary

• PUT /api/providers/[id] unconditionally called enableRateLimitProtection(id) whenever the request body included rateLimitOverrides — even null. EditConnectionModal.tsx sends rateLimitOverrides on every connection save regardless of whether the operator touched that section, so saving any connection silently started queuing its requests through Bottleneck while the DB (rate_limit_protection column) and the dashboard toggle both still showed the feature off.
• Fix: only (re)enable the in-memory limiter when updated.rateLimitProtection — mapped from the persisted DB row — is actually true; otherwise explicitly call disableRateLimitProtection(id) so runtime state can never drift ahead of the DB. rateLimitOverrides refresh (refreshConnectionRateLimits) is preserved unconditionally since it is useful on its own and does not affect the enable/disable toggle.
• rateLimitProtection itself is not (and was not) part of updateProviderConnectionSchema, so this route can only read the persisted value — never set it — closing the drift for good.

Closes #11278

⚠️ base-red inherited: #9985

Test plan

TDD per Hard Rule #18 — tests/unit/provider-patch-ratelimit-protection-11278.test.ts:

• RED (confirmed by code inspection of the base branch's unconditional enableRateLimitProtection(id) call — see diff) → GREEN after the fix: a connection with rate_limit_protection=false in the DB stays with isRateLimitEnabled() === false after a PUT that includes rateLimitOverrides: null, and the DB row itself still shows protection off.

• Control case: a connection with rate_limit_protection=true keeps isRateLimitEnabled() === true after the same kind of PUT.

• node --import tsx/esm --test tests/unit/provider-patch-ratelimit-protection-11278.test.ts — 2/2 pass

• Sibling suites (route + rate-limit-manager): providers-patch-400.test.ts, codex-connection-edit-6562.test.ts, provider-rate-limit-overrides-schema.test.ts, providers-route-patch-method.test.ts, rate-limit-manager.test.ts, ratelimitmanager-headers-split.test.ts — 56/56 pass

• npm run typecheck:core — clean

• eslint on changed files with the project suppressions — clean (the one pre-existing no-restricted-imports warning on route.ts line 7 is already allowlisted in config/quality/eslint-suppressions.json and untouched by this change)