fix: 消耗任务 clamp2 改守恒口径,消除余额快照滞后超烧风险

- b0_est = 拉包时刻 余额+usage (= B0+L,与 v6 闸门同构)
- clamp2: plan ≤ b0_est − SMALL_BUFFER − usage_now; 停止条件 2 改
  usage ≥ b0_est − SMALL_BUFFER,每轮实时读共享 key,真实用户消耗
  结构性计入,两方合计超烧杜绝(残余风险收敛为 §7.5 L 同款)
- 数字用例验证: L=0 撞墙剩 SMALL_BUFFER(旧方案执行中用户耗 100k 超扣 100k)
- docs: §8 排障 4/§9 条目翻转为已实施;新增视觉图片 reserve 估算
  口径校准待确认项(LiteLLM 85/765 OpenAI 口径 vs 火山未公开公式)

docs/volc-quota-notes.md

@@ -396,7 +396,8 @@ reserve = 18输入 + 16声明 = 34，实际消耗 +167/+150（正文 ~16 + 思
    在滞后未收敛时 = B0 + L(虚高)，「实时抵消」仅覆盖同步后窗口，L 不抵消(§7.5)
 3. 判断「还能免费采多少」：保守用 `网页 B0 − 今日已采`；v6 公式在滞后收敛时等价，未收敛时偏高 L
 4. 消耗任务 23:20 直连 Ark 绕过 LiteLLM 闸门(防自杀)，其自身 clamp：`plan ≤ 2M − usage`、
-   `plan ≤ 余额快照 − SMALL_BUFFER`，停止条件三闭环
+   `plan ≤ b0_est − SMALL_BUFFER − usage`（b0_est = 拉包时刻 余额+usage，守恒口径与 v6 闸门同构，
+   2026-08-13 已实施），停止条件三闭环
 5. 余额滞后不改变 B0 守恒；30 天过期蒸发是余额下跌的另一来源，
    与消耗扣减区分(如 08-12 余额 1,558,307 → 596,869，其中约 50 万为滞后修正 + 过期)
 6. 2M 采集上限可被单请求 + 并发击穿(§7.6)：reserve 估算不足时已放行的请求继续消耗，
@@ -417,6 +418,14 @@ reserve = 18输入 + 16声明 = 34，实际消耗 +167/+150（正文 ~16 + 思
 - [x] 2M 采集上限击穿修复(2026-08-12 20:53 实测 §7.6：reserve 改用 token_counter + max_tokens，
       后置 soft_evict 兜底；23:18 重启后 PRE-BLOCK 生效)
 - [x] 消耗任务口径同步收紧(2026-08-13 代码确认：clamp2 用 `vls.SMALL_BUFFER`，与闸门同源一致)
+- [ ] consume clamp2 余额快照口径修复待观测（2026-08-13 已实施守恒口径，待 1-2 个结算周期观测
+      🔴 深夜 L 实际是否 < SMALL_BUFFER；若触发"守恒墙已耗尽"且当日有扣费疑点 → 叠加 A' 收敛重取）
+- [ ] 视觉图片请求 reserve 估算口径未校准（2026-08-13 调查）：LiteLLM `token_counter` 对 OpenAI 格式
+      image_url 按 OpenAI 口径计（detail low/auto = 85 token/图，high = 下载图按 tile 85+170×tiles，
+      失败 fallback ~255），**与火山 Ark doubao 视觉模型实际计费公式不一致**；官方仅提供 Token 计算器
+      工具（未公开公式），FAQ 只说"图片计入输入 token"。闸门调用未传 use_default_image_token_count →
+      high-detail 图会在 hook 内同步下载（阻塞）。偏差量级 = 每图几十~几百 token，相对
+      THINKING_RESERVE_FLOOR(4096) 小；方向待实测（Token 计算器对照或发图看 usage），有图流量时关注
 - [ ] 空窗期(0:00~返还到账)行为观察：v6 下 B0 自动收紧，确认无异常误杀
 - [ ] 数据库泄漏：08-12 一天 deepseek-v4 消耗记录量级约 5 万条导致 Redis 内存膨胀；触发监控/清理机制
 - [ ] v6 无静态 2M 兜底时的安全：08-13 幸由 B0(2,242,178) > 2M 静态墙兜底；若某日 B0 < 2M，
@@ -424,16 +433,16 @@ reserve = 18输入 + 16声明 = 34，实际消耗 +167/+150（正文 ~16 + 思
 - [x] reserve 精度验证(2026-08-13 短文本实证：估算 34 vs 实际 167 的根因 =
       思考模型 reasoning tokens 不计入 reserve，已用 THINKING_RESERVE_FLOOR 兜底；
       token_counter cl100k_base 对中文偏高对输入侧仍是安全方向)
-- [ ] consume clamp2 余额快照口径不同步（2026-08-13 最新思路下确认为**必改项**，推荐方向 C 守恒口径，
-      待实施）：`plan ≤ balance − SMALL_BUFFER` 用拉包时刻余额快照 (volc_consume.py:455)，**不含
-      23:20→00:00 真实用户消耗**；clamp1 用共享 daily_usage 实时精准，但余额维度两方不同步。§4.2 已
-      实测结算滞后 Δ≈14 分钟 → 快照相对真实剩余虚高 L（随消费速度增长，实测 149,616 > SMALL_BUFFER
-      5 万），深夜真实消耗大时两方合计可超烧余额。
-      修复方向（分析 2026-08-13）：
-      - ✅ **C 守恒口径（推荐）**：`_record_consumption` 已将自身 INCR 进共享 daily_usage，每轮
-        `_current_daily_usage` 即"真实用户+自身"总消耗 → `b0_est = balance + usage_now`（= B0+L，与
-        v6 闸门同构），clamp2 改 `plan ≤ b0_est − SMALL_BUFFER − usage_now`、停止条件改
-        `usage ≥ b0_est − SMALL_BUFFER`（与 clamp1 同构）。零 API 成本，两方不同步结构性消除；
-        残余风险 = §7.5 遗留风险 1 同款（L > SMALL_BUFFER 时 b0_est 虚高）。
+- [x] consume clamp2 余额快照口径不同步（2026-08-13 已实施方向 C 守恒口径）：原 `plan ≤ balance −
+      SMALL_BUFFER` 用拉包时刻余额快照 (volc_consume.py:455)，**不含 23:20→00:00 真实用户消耗**；
+      clamp1 用共享 daily_usage 实时精准，但余额维度两方不同步。§4.2 已实测结算滞后 Δ≈14 分钟 →
+      快照相对真实剩余虚高 L（随消费速度增长，实测 149,616 > SMALL_BUFFER 5 万），深夜真实消耗大时
+      两方合计可超烧余额。
+      实施内容（2026-08-13）：`_record_consumption` 已将自身 INCR 进共享 daily_usage，每轮
+      `_current_daily_usage` 即"真实用户+自身"总消耗 → `b0_est = balance + usage_now`（= B0+L，与
+      v6 闸门同构），clamp2 改 `plan ≤ b0_est − SMALL_BUFFER − usage_now`、停止条件改
+      `usage ≥ b0_est − SMALL_BUFFER`（与 clamp1 同构）。零 API 成本，两方不同步结构性消除。
+      数字用例验证：L=0 时撞墙剩 SMALL_BUFFER（旧方案执行中用户消耗 100k → 超扣 100k）；
+      L>0 残余风险 = §7.5 遗留风险 1 同款（L > SMALL_BUFFER 时 b0_est 虚高，与闸门共享，非消耗任务独有）。
       - 🅰 A' 可选叠加：执行前睡 ~15 分钟再拉一次取收敛 balance 算 b0_est（防 L 大，成本 8 次 API）
       - ❌ B 扣减 L 预估：v5 BUFFER 盲猜教训（L 实测浮动 15 倍），否决