Cloudflare gateway adapter drops unmapped usage_metadata fields instead of surfacing them in extras

[anassg-lago]

The Cloudflare gateway adapter maps a fixed set of usage_metadata keys and hardcodes three extras keys, so any field the gateway sends that we don't map is dropped with no error and nothing in extras. That breaks the drift contract the other adapters hold.

Surveying every usage_metadata key across all 14 captured fixtures shows two live examples already:

key	fixtures	mapped?	in extras?
input_tokens / output_tokens / total_tokens	9	yes	—
input_cached_tokens	8	yes	—
neurons	4	no	no
input_cache_creation_tokens	3	yes	—
reasoningTokens	1	yes	—
input_text_tokens	1	no	no

extras is currently {cached, step, log_id} — a hardcoded three, none of them from usage_metadata.

This is the same hole ancorcruz raised on the Databricks gateway adapter in #14 ("the only adapter in the repo with no drift sweep"), sitting in the Cloudflare one. openai_native, mistral_native, bedrock_converse and bedrock_invoke all sweep unrecognized usage keys into extras; these two gateway adapters don't.

Why it matters: neurons is Cloudflare's own compute unit and may become billable; input_text_tokens suggests a modality split we don't model. Either could turn into a real metric, and today it would vanish silently rather than surfacing for follow-up — which is exactly what the drift contract exists to prevent. No current billing impact: neither field is priced.

Suggested fix: sweep unmapped usage_metadata keys into extras under a dotted prefix (usage_metadata.neurons), mirroring what _MAPPED_DETAIL_FIELDS does in adapters/openai_native.py, and add a drift test alongside test_drift.py. Do it in both repos in the same PR pair, per CONTRIBUTING.

Deliberately split out of the Cloudflare connector PR (#13 / getlago/lago-agent-sdk-js#28) to keep that one to review feedback and money paths. Found while fixing the cache-key casing in that PR.

[anassg-lago]

Same class of hole in a second adapter — adapters/gemini_native.py / .ts, worth folding into this issue rather than filing separately.

Its docstring is explicit that only top-level keys are swept: "Unknown top-level usage fields land in extras (drift detection)." The four *_tokens_details containers are listed as KNOWN keys, so nothing nested inside them is ever inspected:

_KNOWN = {..., "prompt_tokens_details", "candidates_tokens_details",
          "cache_tokens_details", "tool_use_prompt_tokens_details"}

And _modality_token_count reads only AUDIO and IMAGE from those lists. So a VIDEO or DOCUMENT modality entry in prompt_tokens_details is mapped nowhere and absent from extras — dropped with no error.

This is precisely the hole commit 2 on the Databricks PR closed for openai_native (which now sweeps one level down into *_tokens_details under dotted keys, after a live gpt-5.6-sol response's prompt_tokens_details.cache_write_tokens: 3022 was found being discarded). gemini_native never got the same treatment.

No billing impact today: Gemini's modality counts sit inside prompt_token_count, which is already billed, so nothing is lost from the charge — it's the drift contract that's broken, not the money. The shape differs from openai_native's too: Gemini's details are lists of {modality, token_count} rather than dicts, so the sweep would surface unrecognized modalities (prompt_tokens_details.VIDEO) rather than unrecognized keys.

Fixing both adapters together makes the contract uniform across every adapter in the repo, which is the reviewer's underlying point on the Databricks one.