Fix HuggingFace usage extraction: defaultapi_flavor and generic huggingface provider

[adtyavrdhn]

This pull request was posted by Codex Desktop using gpt-5.6-sol on behalf of David.

Part of #324 (gaps 2 and 3). Unblocks the HuggingFace migration in pydantic/pydantic-ai#4818.

What this fixes

• Generates both an implicit default extractor and the existing explicit chat extractor for every routed huggingface_* provider. Keeping both flavors preserves existing callers while making the library default work.
• Adds an extraction-only huggingface provider for Hugging Face's server-side auto-routed /v1 endpoint, where the downstream provider is intentionally unknown. It has no models or fallback pricing because assigning a downstream price without provider identity would be ambiguous. Its explicit empty model path makes the public Python API return usage with model=None instead of attempting an impossible model lookup; JavaScript returns the equivalent model: null.
• Maps required prompt/completion totals and optional nested OpenAI-compatible cache, cache-write, audio, and reasoning details. Reasoning is recorded as output_reasoning_tokens, while output_tokens remains the aggregate completion total.
• Adds an extraction-only sync command so existing generated Hugging Face provider files stay aligned even when a provider disappears from the live model listing. Generated v2/package artifacts and the golden usage corpus were regenerated through the repository generators.

The implementation adopts #327's generator-root-cause analysis and its backward-compatible “duplicate default and chat” design option. Both #327 and this PR are by @adtyavrdhn; #327 remains open as the original plan/design record.

Evidence

• Hugging Face documents Inference Providers as a proxy with client- or server-selected routing, including the OpenAI-compatible router endpoint: Inference Providers overview.
• The official HF chat task schema and huggingface_hub generated ChatCompletionOutputUsage type guarantee prompt_tokens, completion_tokens, and total_tokens: chat-completion schema, huggingface_hub generated type.
• Current raw pydantic-ai recordings cover provider variation: Together/DeepSeek response with top-level cached_tokens and Nebius/Qwen response with null nested detail objects.
• Provider-primary schemas confirm that OpenAI-compatible optional details vary: Together compatibility notes and Cerebras chat response schema.

The generic extractor deliberately does not reinterpret Together's provider-specific top-level cached_tokens: HF's formal schema does not define it, response shapes vary by routed provider, and mapping both top-level and nested forms would be additive in the current data-driven contract and could double-count. The exact recorded Together shape is pinned in Python and JavaScript tests to make that behavior explicit.

Validation

• make build
• make lint
• make typecheck
• make test
• npm run ci
• focused Python extractor/source/dataset tests
• focused JavaScript extractor/dataset tests
• tests/dataset/extract_usages.py (golden corpus up to date)
• git diff --check

[cubic-dev-ai]

No issues found across 21 files

Not reviewed (too large): tests/dataset/usages.json (~12,384 lines), packages/js/src/data.ts (~428 lines), packages/python/genai_prices/data.py (~266 lines), prices/data_slim.json (~2 lines), prices/data.json (~2 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

_{Re-trigger cubic}

[cubic-dev-ai]

All reported issues were addressed across 14 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[Kludex]

Closing in favor of #634, which implements the accepted default api_flavor behavior for generated Hugging Face and OVHcloud providers on the current codebase. Thank you for working on this.