fix(resilience): stop hammering permanently-moved endpoints and billing-suspended accounts

[turbolego]

Follow-up to #11762 — same bug class, different providers

After #11762 (Gemini deprecated-model 404 lockout), I checked a fresh 1h request log and found the same underlying bug hitting other providers: a permanent failure signal isn't classified by checkFallbackError, so it falls through to the generic transient-error branch (short, seconds-to-minutes cooldown) and gets retried roughly every cooldown window — forever, since the target can never succeed. Two concrete cases:

1. freeaiapikey — permanently moved API endpoint (410), retried every ~1 minute for the whole hour

"provider": "freeaiapikey",
"model": "anthropic/claude-sonnet-4.6",
"status": 410,
"error": "[410]: This API endpoint has moved. Please update your base_url to
          https://api.freeaiapikey.com/v1 — the old endpoint on
          freeaiapikey.com no longer works."

"provider": "freeaiapikey",
"model": "anthropic/claude-opus-4.6",
"status": 410,
"error": "[410]: This API endpoint has moved. Please update your base_url to
          https://api.freeaiapikey.com/v1 — the old endpoint on
          freeaiapikey.com no longer works."

This recurs at 08:52, 08:53, 08:56, 08:57, 09:01, 09:02, 09:05, 09:16, 09:19 — i.e. roughly every 1–3 minutes, non-stop, for both claude-sonnet-4.6 and claude-opus-4.6. The base_url is stale and will never succeed until an operator updates it, but nothing in checkFallbackError recognized "endpoint has moved / no longer works" as permanent, so it kept getting the same short cooldown as a normal transient error.

2. fireworks — account suspended for billing (412), also retried every ~1 minute

"provider": "fireworks",
"model": "deepseek-v4-pro",
"status": 412,
"error": "[412]: Account hummern is suspended, possibly due to reaching the
          monthly spending limit or failure to pay past invoices. Please go
          to https://fireworks.ai/account/billing for more information."

Two problems compounded here:

• 412 isn't in checkFallbackError's retryableStatuses set at all, so it never got dedicated handling.
• The wording ("Account hummern is suspended...") doesn't match ACCOUNT_DEACTIVATED_SIGNALS' fixed substring "your account has been suspended" — different phrasing, different provider.

Result: the same suspended Fireworks account got hit dozens of times over the hour with a request that can only ever fail until the invoice is paid.

The fix

In open-sse/services/accountFallback.ts (mirrors the pattern from #11762):

• ENDPOINT_PERMANENTLY_MOVED_PATTERNS + isEndpointPermanentlyMoved() — matches "endpoint has moved", "no longer works", "update your base_url". A 410/404 matching this now gets a 24h lockout (reason: "not_found", surfaced via quotaResetHintMs so combo's per-request model-lockout honors it in full instead of the normal ~20min ceiling).
• ACCOUNT_SUSPENDED_BILLING_PATTERNS + isAccountSuspendedForBilling() — matches "suspended ... spending limit/billing/invoice/payment" in either word order, independent of status code (so it also catches Fireworks' un-mapped 412). Classified the same way as an existing credits-exhausted account (creditsExhausted: true, 1h cooldown) so it reuses the existing credits_exhausted terminal connection status and self-heals if the invoice gets paid.
• Both checks are narrowly scoped (specific phrasing, not a blanket "anything with 410/412 is permanent") so unrelated 410/412 responses are untouched and still fall through to the existing short-backoff path.

Testing

Added tests/unit/permanent-failure-hammering-other-providers.test.ts (7 tests, all passing):

• isEndpointPermanentlyMoved matches freeaiapikey's exact phrasing, doesn't match a generic "[410]: Gone".
• isAccountSuspendedForBilling matches Fireworks' exact phrasing, doesn't match an unrelated suspension message.
• checkFallbackError returns a 24h lockout for the moved-endpoint 410.
• checkFallbackError returns creditsExhausted: true for the billing-suspended 412.
• A generic 412 with no billing-suspension phrasing still falls through unchanged (no regression).

Ran locally:

node --import tsx/esm --test tests/unit/permanent-failure-hammering-other-providers.test.ts
# 7/7 pass

node --import tsx/esm --test tests/integration/gemini-rate-limit-classification.test.ts \
  tests/unit/account-fallback-service.test.ts tests/unit/error-classification.test.ts \
  tests/unit/agentrouter-error-rules.test.ts
# 147/147 pass, no regressions

Also registered the new test in stryker.conf.json's tap.testFiles (learned from CI on #11762 that this is required for the mutation-test-coverage gate).

Files changed

• open-sse/services/accountFallback.ts — new pattern sets + classification branches.
• tests/unit/permanent-failure-hammering-other-providers.test.ts — new regression test.
• stryker.conf.json — register the new test file.