Refactor provider layer into smaller capability modules

[1jehuang]

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.