渠道主动健康探测：后台 GET /models + 候选排序沉底 + 用量口径隔离

### 现状（如实声明）

故障切换是**纯被动**的：`channel_mode_health`（迁移 020）按（渠道×端点×流式）连续失败冷却剔除、成功即清除；另有手动测试列 `last_test_*`。**没有主动探测**——上游恢复后第一个真实用户请求当探针、失败体验由用户承担；渠道「当前健康度」没有持久状态与后台维护。

### 方案

- **探测循环**：默认 300s 一轮（`probe.interval_secs`，最短 30s）、`probe.enabled=false` 可整体关闭（关闭时零后台流量）；对启用中的 API 渠道发 `GET {base_url}/models`（带渠道 Key、10s 短超时）；**Auth 账号渠道零探测**（成本与配额敏感）。
- **迁移 033**：channels 加 `last_probe_at`/`last_probe_ok`/`probe_latency_ms`（NULL=从未探测，排序视为健康）+ `request_logs.is_probe`（默认 0）。
- **沉底不剔除**：两轨候选查询统一追加 `COALESCE(last_probe_ok, 1) DESC` 排序键——探测失败渠道沉底但仍在候选内（保守，避免误杀），同健康档保持既有优先级/权重序。
- **被动反哺**：两轨真实请求传输成功顺带 `mark_probe_ok`——一次真实成功即恢复排序位。
- **口径隔离**：探测写 is_probe=1 日志行（透明可查），仪表盘/日志统计/模型统计/渠道统计/Key 统计/Token 趋势全部排除探测行——用户账单零污染。
- **正交声明**：mode_health 冷却语义零改动（GET /models 可达 ≠ 聊天模式健康，互不写对方的表）。
- 管理端：设置页探测区；渠道卡片健康状态点（探测列优先，无探测数据回退手动测试列）。

### 如实列出

legacy 轨不受 mode_health 冷却是**上游既有现状**（两轨候选查询不同），本 PR 的排序沉底已在两轨同时生效。

### 测试

探测步骤（mock 端点健康 + 不可达端口渠道 → 列更新 + is_probe 日志）、关闭时零流量零写入零列变更、三渠道排序沉底断言、for_mode 查询沉底（两轨一致）、被动反哺恢复排序、用量统计排除断言。

### 开放点

1. 连续 N 次探测失败是否自动禁用渠道（本 PR 只沉底不剔除，保守）？
2. 探测路径是否需要按渠道类型可配置（自定义 base_url 渠道目前同走 /models）？

---
对应分支：`feat/capability-c04-health-probe`（迁移 033）。

Start by reviewing migration 033 and the feat/capability-c04-health-probe branch, then trace the probe loop, both candidate queries, and the statistics paths named in the issue. Done means the listed probe, disabled-mode, ordering, passive-recovery, and usage-exclusion tests pass, while the two open design questions are resolved.

Written by the indexing model from the issue text.