feat(metering): emit provider and reasoning tokens in usage CloudEvents

[crstrn13]

Problem

Metering CloudEvents (inference.tokens.used) were not fully configurable from the deployment. The provider/cluster attribute was derived from ctx.cluster_name(), but the ext-proc adapter hard-codes cluster: None and there was no config field to set it — so the controller could not render a correct value. Reasoning tokens were also not surfaced in the usage event.

See opendatahub-io/praxis-extproc#80.

Changes

• Add a provider config field to the external_metering filter so the emitted CloudEvents carry a statically configurable provider, independent of ctx.cluster_name().
• Emit reasoning_tokens in the usage CloudEvent when present.
• Update examples/configs/external-metering.yaml, filter docs, unit tests, and the example integration suite to cover the new field and reasoning-token emission.

Tests

• Unit tests in filters/src/metering/tests.rs.
• Example integration coverage in the external metering suite.

Refs opendatahub-io/praxis-extproc#80

[praxis-bot]

Review: feat(metering) — provider and reasoning tokens

The metering changes are clean, well-structured, and thoroughly tested. Provider resolution with static config > cluster name > empty fallback is correct and covers the ext-proc data path where cluster_name() is always None. Reasoning token plumbing from token_count metadata through TokenCounts into the CloudEvent is straightforward. Tests cover all three provider resolution branches, reasoning token round-trip, and the zero-default case.

One scope concern below.

Findings: 1

[praxis-bot]

[Medium] This 438-line file adds credential-store parity acceptance tests that are unrelated to the metering provider/reasoning-token feature. The PR description does not mention it, and the commit (ca94a64a) is a separate concern. Consider splitting this into its own PR so each change set can be reviewed and reverted independently.