fix: v5 恢复 v2 骨架，修正 v4 误拦

v4（stable = balance - BUFFER）把「剩余余额」当「从 0 累计的上限」，
U>0 时低估初始池：15:09:51 实测 Bal=596,869（剩 59.7 万）却被
usage 1,696,135 >= 296,869 全拦。守恒反推（U+B=2,293,004）证明
v2 公式数学正确——B 滞后收敛后满足 B = B0 - U，今日消耗 1.696M <
B0 2.293M 无扣费（此前「超余额 13.8 万扣费」基于滞后快照的推断
不成立）。v5 = 恢复 v2（stable = usage + balance - BUFFER），
残留风险仅同步时点 B 滞后（13:36 高估 ~50 万），由 BUFFER + 低余额
加密同步覆盖。文档同步：volc-quota-notes §7.3/§7.5、merge-auto-consume §4.5。

AGENTS.md

@@ -7,7 +7,7 @@
 - **核心逻辑**：通过 `quota_interceptor` 拦截请求，并通过 `DailyLimitHandler` 记录用量到 Redis。后台 `active_monitor_loop` 守护线程定期从火山引擎 API 同步配额到 Redis。
 - **架构**：主逻辑在 `volc_limit_sync.py`（限额 + 同步守护 + 每日消耗调度），消耗任务拆分在 `volc_consume.py`（每日北京时间 23:00 由守护线程延迟导入触发；见 `merge-auto-consume.md`）。LiteLLM 通过 `config.yaml` 中 `callbacks: ["volc_limit_sync.proxy_handler_instance"]` 加载回调，模块加载时自动启动后台同步线程。
 - **关键文件**：
-  - `volc_limit_sync.py`: **核心文件**，包含同步守护线程（`active_monitor_loop`）、LiteLLM 回调（`DailyLimitHandler` + `quota_interceptor`）、限额计算（v4 冻结快照：`stable_limit = balance − BUFFER`，`effective_limit = min(2M 采集配额, stable_limit)`；扣费红线 = 余额，与采集量/返还无关，见 `docs/volc-quota-notes.md`）、模型屏蔽/恢复、以及每日 23:00 消耗任务调度（`_maybe_trigger_daily_consume`，SETNX 去重）。
+  - `volc_limit_sync.py`: **核心文件**，包含同步守护线程（`active_monitor_loop`）、LiteLLM 回调（`DailyLimitHandler` + `quota_interceptor`）、限额计算（v5：`stable_limit = usage + balance − BUFFER`，`effective_limit = min(2M 采集配额, stable_limit)`；当日初始免费池守恒，扣费判定见 `docs/volc-quota-notes.md`）、模型屏蔽/恢复、以及每日 23:00 消耗任务调度（`_maybe_trigger_daily_consume`，SETNX 去重）。
   - `volc_consume.py`: 消耗任务模块（每日 23:00 触发；手动 `python volc_consume.py --dry-run` / `--force`）。复用 volc_limit_sync 的拉包/归一化/用量记账设施，直连 Ark API 洗即将过期的免费资源包（防 30 天过期蒸发）。
   - `config.yaml`: LiteLLM 配置文件，包含模型定义和回调配置。
   - `docker-compose.yml`: 容器编排，仅挂载 `config.yaml`、`volc_limit_sync.py`、`volc_consume.py`。