docs(tasks): 缓存生效后剩下的两块——外网健康探测与运行时重复编译

在 f8e607c2 上重测：BUG-727 的快照缓存确实每轮命中、响应体 52 万→40 万
字符，但耗时几乎没变。6 次调用累计 5.30 s，网络仍占 70%（poll 2.42 +
ssl read 0.76 + 握手 0.56），本地 swisseph 只剩 2.4%。

- BUG-734：剩下那一次外网是 gateway_status 的健康探测。它不是 ping——
  probe_calculate_health 把一份虚构排盘 POST 给 api.vedastro.org，并且
  consume_rate_token() 会烧掉对方一个业务限流令牌；opener 默认 None，
  每次新建 TLS（6 次调用 3 次握手，单次 0.186 s）；结果零 TTL。
  修法：成功 60 s / 失败 10 s 的 TTL，配置变即失效，诊断端点走
  force_refresh 保持实时；共享 opener 摊掉握手。
- BUG-735：yoga_engine._eval_custom 对 references/yoga_rules.json 的
  192 条静态表达式每请求重新编译 102 次，多语句的还要先抛一次
  SyntaxError 再 parse + 改写 AST + compile，占 9.4%。
  修法：lru_cache 存 (mode, code object)。硬红线：绝不缓存求值结果，
  那会跨用户串盘。

等价证明沿用 BUG-733 的同进程差分，不再写跨机 golden。

纯文档推送，不触发门禁、不发布镜像、不部署。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JUei7K13cYxLHE3Axe4A45

docs/tasks/README.md

@@ -244,6 +244,7 @@
 | `TASK-freeze-metric-change-20260915.md` | — | **规则单（后面两单的前置，无 BUG 号）**：两条增长冻结余量都用完（`page.tsx` 1,951/1,951 余 **0**；`jyotish_api_server.py` 11,334/11,363 余 **29**），冻结从「逼新代码往外走」退化成「拦路」。实证：`page.tsx` 行数砍 59% 但 `Home()` 的 `useState` 从 56 涨到 **66**（拆的是代码不是状态）；api server **225 个类方法只有 12 处真碰 HTTP 上下文**，4 处 `__new__` 伪造空壳就是这么来的。**产品拍板换口径**：主门改成「`Home()` 的 useState/useRef 不得增长」与「类方法数 + `__new__` 计数不得增长」，行数降级为粗护栏；**同时推翻 §6「参数式 hook 内部保持 0 个 React hook」**（那正是状态搬不走的原因）。改 `AGENTS.md` §6 + 两个合同测试，不碰业务代码 | 待领取 | — |
 | `TASK-home-state-lowering-20260915.md` | — | **page.tsx 状态下沉第一簇（串行在 freeze-metric-change + C2 + R3 之后）**：66 个 state 里 `rectification*` 占 **15** 个，而它们服务的 `<ConversationalBirthTimeRectification>` 本来就是 `dynamic()` 懒加载子树、挂着 24 个 props；`useRectificationSurface` 要解构约 56 个参数。把这簇搬进子树，`Home()` 的 useState 从 66 降到 ≤ 53。**零行为变化**；第一步必须先把 15 个逐个分类（只服务子树 / 外壳也要读）。产品否决了 Context Provider 与外部 store 两条路。不占 BUG 号 | 待领取 | — |
 | `TASK-rectification-engine-memoization-fix-20260915.md` | — | **验收修复单（只改测试，一行实现不许动）**：BUG-721 的实现**等价性成立**（我在改前 `6b3248bf` / 改后 `e4788dfc` 同机跑同一 payload，`candidate_scores` 逐字相同），9 条计数断言全过；但等价 golden 在本机复现不出来——4 处浮点尾数差（score 1.0e-4 ×2、`margin_percent` 1.1e-3 ×2）。**复发自 BUG-712**（「不得对全精度浮点做整体 `==`」，那一单只落在 ephemeris 一处）。而 `tests/test_rectification_*.py` 在 `CORE_PYTEST_TARGETS` 里，**staging 门禁靠机器舍入碰巧一致才是绿的**。修法：主证据换成**同进程差分**（把 static context 的四个缓存键置 `None` 即可回退旧路径，A/B 严格相等），golden 降为离散字段严格相等 + 浮点带容差（容差按实测 1.1e-3 推）；**禁止重建 golden 来「修」**。另含六份 golden 的仓库级排查。BUG-733 | 待领取 | — |
+| `TASK-consultation-residual-hotspots-20260916.md` | — | **性能单（与拆解单文件不重叠，可并行）**：BUG-727 的快照缓存已验收生效（逐轮 trace 确认每轮 hit、响应体 52 万→40 万字符），但耗时没降——重测 6 次调用 5.30 s 里**网络仍占 70 %**（poll 2.42 + ssl read 0.76 + 握手 0.56），本地占星计算只剩 **2.4 %**。剩下那一次外网是 `gateway_status → probe_official_rest_health → probe_calculate_health`：**它不是 ping，是把一份虚构排盘 POST 给 `api.vedastro.org`**，而且 `consume_rate_token()` 会**烧掉对方一个业务限流令牌**，还不复用连接（6 次调用 3 次 TLS 握手，单次 0.186 s），结果零 TTL（BUG-734）。另 `yoga_engine._eval_custom` 对静态规则表的 192 条表达式**每请求重新编译 102 次**（多语句的还要先抛一次 SyntaxError 再 parse+改写 AST+compile），占 9.4 %（BUG-735）。修法：探测加 TTL（成功 60 s / 失败 10 s，配置变即失效，**诊断端点必须 force_refresh 保持实时**）+ 共享 opener；表达式缓存 code object。**硬红线：绝不缓存 yoga 求值结果**（会跨用户串盘）。等价证明用 BUG-733 的同进程差分，不再写跨机 golden。BUG 段 734–735 | 待领取 | — |
 
 ## 命名与归档