quota aggregator: exempt declared key-validity (console-only) providers from the no-data error degradation #6087

Problem

The pm-stack quota aggregator degrades any provider run whose entries carry no measured window: finalizeRun in pm-stack/aggregator/scripts/gather-quota.ts flips ok entries to state: "error" with the reason no-data: provider reported ok but no window carried a percentage (mapper rule in pm-stack/aggregator/src/quota-gather-map.ts, entryFromResult). That rule is correct for its motivating case (Meta's post-roll ok-but-null shape silently replacing last-good percentages since 2026-11-03).

It is wrong for key-validity-class providers — providers whose credential class provably cannot expose a usage window and which declare that honestly. The first such provider landed 2026-11-05: openchamber's mistral provider (developing-today-forks/openchamber#1619, PR #1633, merged). Mistral usage/balance return 404 for a standard API key and the Admin usage API is Enterprise-only, so the provider reports key validity with usage { windows: {}, usageAvailability: 'console-only' }. Every production tick now shows mistral as a permanent error / no-data — indistinguishable from a broken read, and it trains exactly the ok-but-null blindness the rule exists to prevent, in reverse.

Ask

Exempt entries from the no-data degradation when the provider result declares the key-validity class. The declaration channel already exists: the mapper copies result.usage onto the entry verbatim, and the mistral provider sets usage.usageAvailability: 'console-only'. Rule change, either in the mapper or in finalizeRun:

• If every ok entry of a run carries usage.usageAvailability === 'console-only' (or an equivalent declared marker the aggregator chooses), keep state: "ok", do not attach the no-data error, and let perf(quota-plane): parallel provider fetching + per-provider timeout budget for the 15-min tick #1268 retention treat the entry as a healthy credential-watch row.
• Meta's case must stay an error: it declares no such marker (its windows exist; their percentages are null), so the existing rule keeps firing there unchanged.

Add a case to pm-stack/aggregator/test/quota-gather-map.test.ts (or the gather-quota equivalent): a console-only-declared provider stays ok; an undeclared ok-but-null provider still degrades.

Evidence

Production quota-current.json (laptop, tick 2026-11-05T06:03:33Z, gatherer service on merged openchamber main 36e12d7b8):

{
  "providerId": "mistral",
  "state": "error",
  "credentialWatch": true,
  "credentialLabel": "Mistral (drewrypope)",
  "usage": { "windows": {}, "usageAvailability": "console-only" },
  "error": "no-data: provider reported ok but no window carried a percentage"
}

The provider result behind it was ok: true (key verified live against GET /v1/models).

Acceptance criteria

• An entry whose provider result declares usage.usageAvailability === 'console-only' (all ok entries of the run) keeps state: "ok" through finalizeRun — no no-data error is attached.
• An undeclared ok-but-null provider (the Meta shape) still degrades to error with the existing no-data reason — the original rule is unchanged for that case.
• A regression case in pm-stack/aggregator/test/quota-gather-map.test.ts (or the gather-quota equivalent) covers both directions: console-only-declared stays ok; undeclared ok-but-null degrades.
• perf(quota-plane): parallel provider fetching + per-provider timeout budget for the 15-min tick #1268 retention treats the console-only entry as a healthy credential-watch row.