feat(cockpit): expose granular token dimensions in the models view

[placerda]

Context

ModelUsage currently reports input and output tokens. Modern model families bill several
token classes at materially different rates, and cached, reasoning and long-context tokens
are not separable in the current contract.

This blocks two distinct operator needs. Provisioned throughput customers cannot compute a
burn-down rate, because the commitment is consumed by classes they cannot see. Any customer
trying to reason about the true cost of a request cannot do so when several rate classes
are collapsed into two numbers.

The gap widens as model families diverge. A contract that only models input and output is
already behind the deployments it observes.

What already exists

• ModelUsage aggregated by project, agent, deployment and model
• The principle that missing dimensions remain null and are not synthesized
• CoverageResult already has a token usage dimension
• FR-032 already fixes the correct labeling for these values

Scope

Extend ModelUsage with a normalized token dimension set. Each dimension is nullable and
is populated only when the source telemetry reports it.

Proposed dimensions are cached input tokens, reasoning tokens, and a long-context
classification, in addition to the existing input and output totals. The exact vocabulary
is the main open question below.

Define the normalization contract explicitly. Different model families and different
instrumentation libraries name these attributes differently. The mapping from source
attribute to normalized dimension must be documented and testable, not implicit in query
code.

Extend the existing CoverageResult token usage dimension so it can report partial
coverage. A model reporting only input and output should surface partial, with a
next_action naming what is missing, rather than silently reporting nulls.

Preserve FR-032 verbatim in the presentation layer. These remain observed usage values.

Agent types in scope

Every runtime that reports token attributes on inference spans. This covers Foundry hosted,
Foundry prompt, external registered and external unregistered agents.

Copilot Studio is explicitly excluded from this issue. It meters in Copilot Credits rather
than tokens, so a token dimension set does not describe its consumption. Copilot Studio
consumption is addressed in #443.

Coverage must include non-Microsoft model families available through the platform, not only
first-party deployments.

Out of scope

• Any monetary value or rate table
• Any per-token pricing
• Copilot Studio credit accounting
• Synthesizing a dimension from a total when the source does not report it

Acceptance criteria

• Each new dimension is null when unreported and is never derived by subtraction
• The models view renders a model family reporting only input and output without regression
• The source-attribute to normalized-dimension mapping is covered by tests for at least
  two distinct model families
• The token usage coverage dimension reports partial when only a subset is present
• No new value is labeled as cost or billing anywhere in the response or the UI

Open questions

• What is the minimum normalized vocabulary that is stable across families today, given
  that this was the unresolved telemetry-contract question carried over from the
  foundation work?
• Should long context be a token dimension or a request-level classification? It behaves
  more like a rate tier than a token class.
• Do we normalize vendor-specific classes, or expose them unnormalized alongside the
  normalized set?