fix: register a real Firefly auth probe for the firefly/adobe-firefly alias pair (#10522)

[diegosouzapw]

Closes #10522

Root cause

validateProviderApiKey() in src/lib/providers/validation.ts never reached a real auth check for Adobe Firefly connections. WEB_COOKIE_PROVIDERS is keyed by the canonical id "adobe-firefly", but connection.provider is commonly stored as the short alias "firefly" (same prefix as the firefly/<model> routing ids). The web-cookie fallback did a raw WEB_COOKIE_PROVIDERS[provider] lookup with no alias normalization, so it missed the table for alias-keyed connections — the exact pattern already handled correctly elsewhere (src/sse/services/auth.ts:412: resolveProviderId(provider) in WEB_COOKIE_PROVIDERS). Even with that fixed, Firefly has no entry in the chat providerRegistry (it's image/video-only, registered only in imageRegistry.ts/videoRegistry.ts), so the generic web-cookie probe's getRegistryEntry(provider) always returned null and every Firefly "Test Connection" fell into the { valid: false, error: "Provider validation not supported", unsupported: true } fallback — regardless of whether the pasted cookie/JWT was valid.

Note: the other claim in #10522 (routing a Firefly image model to /v1/chat/completions returns an error telling the caller to use /v1/images/generations) is intentional, correct behavior — OmniRoute's image-model guard — and is not touched by this PR.

Fix

• New src/lib/providers/validation/adobeFirefly.ts — validateAdobeFireflyProvider() reuses the already-working credits/balance probe (getAdobeFireflyUsage(), used today by the Limits/quota page) as a real auth signal: a fetched balance means the token is valid, a { message } result means it was rejected, and thrown transport errors route through toValidationErrorResult().
• Registered under both "adobe-firefly" and "firefly" in SPECIALTY_VALIDATORS (that map is looked up by the raw, unresolved provider string).
• Normalized the WEB_COOKIE_PROVIDERS[provider] fallback lookup with resolveProviderId(), mirroring the existing pattern in src/sse/services/auth.ts.

Regression test

tests/unit/firefly-cookie-validation-10522.test.ts (new, 5 tests):

• resolveProviderId('firefly') stays 'adobe-firefly' (guards the dual-key registration).
• firefly alias and adobe-firefly canonical id both dispatch to the real validator, not the generic unsupported fallback.
• An expired/invalid token probe reports valid:false with a real error message.
• A genuine credits-balance payload reports valid:true.

Fail → pass evidence (repro probe from the plan-file, _tasks/pipeline/bugs/2-implementing/10522-firefly-cookie-validation-alias-miss.plan.md):

• RED before the fix: AssertionError: expected a real Firefly auth probe, but got the generic "unsupported" fallback: {"valid":false,"error":"Provider validation not supported","unsupported":true}
• GREEN after the fix, and all 5 new regression tests pass.

Gates run

• node --import tsx/esm --test tests/unit/firefly-cookie-validation-10522.test.ts — 5/5 pass
• Existing validation-adjacent suites (aihorde-key-validation, bytez-validation-5422, bailian-coding-plan-provider, azureAiMultiModelTest, alibaba-provider-regions, devin-cloud-agent-validator-6142, repro-6142-devin-cloud-agent-unwired) — 74/74 pass, no regressions from the resolveProviderId normalization
• node scripts/check/check-file-size.mjs — OK
• node scripts/check/check-changelog-integrity.mjs — OK
• npm run typecheck:core — clean, exit 0
• npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> — clean, no output
• check-complexity.mjs / check-cognitive-complexity.mjs were attempted locally but did not finish in a reasonable time on this devbox due to heavy parallel-session contention (~60 concurrent worktrees); the diff is a single small leaf function plus one object-literal entry and a resolveProviderId() wrap, so complexity/cognitive-complexity ratchet risk is negligible — CI will gate this independently.

⚠️ base-red inherited: #9985