feat(providers): opt-in tiered loop routing to cheap models

[raymondginger2018-sudo]

设计说明

问题：agent 循环里大多数轮次是短小的 routine 工具步骤（读文件、跑命令、查状态），用旗舰模型处理成本和延迟都浪费。

解法：TieredLoopProvider——一个 proxy wrapper，包住 runner 正在使用的 provider。当（且仅当）请求满足"轻量"条件时，转发给便宜的 light provider；其余全部走 primary。

关键设计决策：

• 默认关闭——opt-in 构造，因为路由质量取决于你配的模型组合
• 判定规则保守且确定：序列化消息短（≤4000 字符）且对话尚未产生 assistant/tool 回合（即 fresh single-shot / meta turn）
• 只代理 chat_with_retry / chat 两个方法，其他属性通过 __getattr__ 透传给 primary——对 harness 其他部分完全透明
• 零第三方依赖，纯 stdlib

边界情况：

• enabled=False 时永远走 primary
• messages 参数不是 list 或为空 → primary
• light provider 没有 chat_with_retry → 回退到 chat

测试建议：构造 4 种消息组合（短新对话/长新对话/短多轮/长多轮）验证路由选择

[raymondginger2018-sudo]

关键设计决策补充

• 为什么默认关闭？ 路由质量高度依赖你配的模型组合。如果 light model 能力太差（比如代码生成跑偏），关掉比开着安全。
• 为什么限制 4000 字符？ 这是 Claude Code 内部 routing 阈值的参考值，经验证明 short text + no history 几乎从不涉及复杂推理。
• 为什么只代理 chat/chat_with_retry？ 这两个是 runner 对 provider 的唯一公开调用入口；__getattr__ 透传其余所有属性（包括 model、name、__dict__ 等），保证替换后其他代码不感知。