fix(usage): declare the Adobe Firefly usage fetcher the dispatcher already calls

[maxmad64bis]

Summary

usage/fetcherProviders.ts says of itself that it exists "so the registration list can't drift from the dispatcher's switch statement", and asks whoever adds a case to remember to add it here too.

It drifted. #8006 added adobe-firefly and firefly to the dispatcher and to USAGE_SUPPORTED_PROVIDERS, but not to this list. So the connection UI says usage is supported while the provider-plugin manifest, genericQuotaFetcher and the free-access quota cache all report no usage fetcher — when getUsageForProvider will happily call getAdobeFireflyUsage for either id.

Nothing suggests this was deliberate. git log -S adobe-firefly on both files turns up exactly one commit, the one that added the feature. No guard, no comment, no test excludes them.

Declaring them is what makes the balance actually get fetched: registerGenericQuotaFetchers wires a generic fetcher for every declared id, and resolveFreeAccessState stops returning early. That's the intended effect, not a side effect — worth stating plainly since two more providers now take part in quota refreshes.

The test is the enforcement the docstring asked for in prose. It reads the dispatcher's cases from the source and compares both directions, so a case without a declaration fails, and so does a declaration the dispatcher would never reach.

It also records the differences between this list and USAGE_SUPPORTED_PROVIDERS, each with a reason. Those sets aren't meant to converge — aggregators like openrouter have a fetcher without being surfaced as a usage-reporting account — but an unexplained difference now fails, so the next drift can't hide among the accepted ones. xiaomi-mimo-token-plan is in there as a real gap: declared supported, no fetcher. Left alone rather than widen this PR.

Related Issues

• Related to feat(media): Adobe Firefly image + video generation provider #8006
• Related to feat(providers): expose a usage-fetch capability in the provider plugin manifest #11903

Validation

• Change type: provider
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Red before green: 2 of 4 cases failed on the unmodified list — the undeclared pair, and the unexplained difference between the two sets. After adding the two ids, 4/4. Measured on the base: the dispatcher handles 49 ids, the list declared 47, USAGE_SUPPORTED_PROVIDERS lists 46.

npm run lint exits 2 here and on an untouched checkout of the base alike (suppressions left that do not occur anymore, zero reported errors).

Tests Added Or Updated

• tests/unit/usage-fetcher-registration-coverage.test.ts (new, 4 cases)

Coverage Notes

The production change is two strings in a const array. The test covers the invariant that array exists to hold, in both directions, plus the recorded divergences and a staleness check so they can't outlive the difference they explain.

Reviewer Notes

• The test reads usage.ts as text rather than importing it: pulling in the dispatcher drags its whole fetcher graph — DB, sockets, child_process — which is exactly the weight fetcherProviders.ts was extracted to avoid.
• It anchors on switch (provider) { and stops at that switch's closing brace. Anchoring on the first switch would land in a doc comment twenty lines above, and running to end-of-file would let a future switch contribute cases to an invariant that isn't about it.
• Neighbours feat(providers): expose usage-supported in provider plugin manifest #12214 and feat(usage): add Kilo Code balance and Kilo Pass quotas #12178 touch the same file for different reasons; no overlap with these two lines.