Refactor provider layer into smaller capability modules

Summary

src/provider/mod.rs has become a large mixed-responsibility abstraction. It currently combines provider trait definitions, routing/config logic, auth handling, failover behavior, pricing/model concerns, and shared HTTP helpers in one place.

Why this matters

• hard to reason about provider boundaries
• high change surface for unrelated provider work
• capability additions keep widening one trait/module instead of composing smaller pieces
• discourages testing at smaller seams

Proposed direction

Split the provider layer into smaller capability-focused modules and traits, for example:

• core provider trait and shared response types
• auth and token refresh support
• routing and model selection
• pricing/model metadata
• shared HTTP/SSE/WebSocket helpers
• optional capabilities such as compaction, native tools, reasoning/service-tier controls

Suggested acceptance criteria

• src/provider/mod.rs is materially smaller and mostly orchestration/reexports
• provider capabilities are grouped behind narrower traits or structs
• shared HTTP helpers live outside the core provider trait module
• at least one provider implementation is simplified by the new boundaries
• validation remains green under fmt/check/clippy

Notes

This is architecture debt follow-up after the quality-enforcement/clippy-clean pass.

Start by reading src/provider/mod.rs and mapping its provider traits, routing/configuration, authentication, failover, pricing/model metadata, and HTTP helpers. Review at least one provider implementation to identify boundaries for narrower capabilities. Done means the module is mostly orchestration or reexports, one provider is simplified, and fmt, check, and clippy remain green.