perf(consultation): 健康探测加 TTL、yoga 表达式只编译一次

BUG-734: probe_official_rest_health 不是 ping —— 它把一份虚构 smoke 排盘
POST 给官方 HoroscopePredictions（实测单次 1,034 ms），还经 call() 吃掉对方
每分钟 5 个限流令牌之一，而结论零 TTL。连续 6 轮前台请求下，第 6 次探测会被
本地限流器挡下、反过来报出假的 official_blocked，真正的业务调用还要和它抢令牌。

加进程级 TTL 缓存（成功 60 s / 失败 10 s，配置变即失效，缓存键只记 key 配没配
的布尔）。force_refresh 默认 True：诊断端点调的是裸 gateway_status() 且该文件
本轮不得改，默认实时才不会让运维看到旧结论；run_gateway_packet 显式走 False。
探测在锁外执行。6 轮实测：探测 6→1、握手 5→1、限流令牌 6→1。

连接复用（任务书 6.2）按让步顺序砍掉：实测 urllib.request 没有连接池，模块级
共享 opener 在 6 次请求下仍开 6 条 TCP 连接，按任务书写法只能骗过「同一个
opener 实例」的断言而省不掉任何握手。另立单。

BUG-735: yoga_engine._eval_custom 对静态规则表的表达式每请求重新编译。实测每次
检测 386 次源码编译（182 次 eval 字符串 + 204 次 ast.parse/compile）。拆出
_build_custom_exec_globals（每次新建，绑定当前盘 ctx）与 lru_cache 的
_compiled_eval_code / _compiled_exec_code，只缓存 code object，绝不缓存求值
结果。求值语义逐条对齐改前。第二次检测起编译 0 次，单次 27.4 ms → 3.3 ms。

等价用同进程差分（BUG-733 的做法）：192 条去重表达式 × 3 张公开虚构示例盘，
与逐字复刻的改前实现同值，另有反向验证证明差分非恒真。

未改 scripts/jyotish_api_server.py。既有断言一条未改。新增 23 条测试。
快速门唯一红的 test_chat_page_uses_authenticated_cloud_persistence 经干净
origin/staging 检出复跑确认为基线红，记入 BLOCKED.md BLK-002，不顺手修。

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

docs/tasks/README.md

@@ -244,7 +244,7 @@
 | `TASK-freeze-metric-change-20260915.md` | `PROGRESS-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 + 两个合同测试，不碰业务代码 | 已验收 | `3b17c1b2`。`AGENTS.md` §6 已按新口径改写，两个合同测试到位 |
 | `TASK-home-state-lowering-20260915.md` | `PROGRESS-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 号 | 已验收 | `f8e607c2`。实测 useState 66→52、useRef 41→39、残留散装 `rectification*` state 0；冻结基线**往紧里收**；全量套件两侧完全相同（3329/fail 31）。遗留：`createRectificationShellSetters` 身份不稳多 1 条 warning，已披露，并进第二批 |
 | `TASK-rectification-engine-memoization-fix-20260915.md` | `PROGRESS-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 | 已验收 | `2b7b4565`（BUG-733）。同进程差分立为主证据，golden 降为离散严格+浮点容差；本机 14 条全绿 |
-| `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 | 待领取 | — |
+| `TASK-consultation-residual-hotspots-20260916.md` | `PROGRESS-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 | 待验收 | `codex/consultation-residual-hotspots-20260916`：6.3 探测 TTL 与 6.1 编译缓存均完成，**6.2 共享 opener 按让步顺序砍掉**——实测 `urllib.request` 无连接池，模块级共享 opener 在 6 次请求下仍开 6 条 TCP 连接，按任务书写法只能骗过「同一个 opener 实例」的断言而省不掉任何握手，另立单。同口径实测：6 轮前台请求探测 6→1 次、握手 5→1 次、对方限流令牌 6→1 个（**改前第 6 轮探测自己被限流、报出假 `official_blocked`**）；yoga 每次检测源码编译 386→第二次起 0，单次 27.4→3.3 ms。等价用 192 条表达式 ×3 盘的同进程差分。`force_refresh` 默认取 `True`（与任务书写的 `False` 相反）：诊断端点调的是裸 `gateway_status()` 且该文件不得改，默认实时才不会让运维看到旧结论 |
 | `TASK-home-state-lowering-batch2-20260916.md` | — | **状态下沉第二批（纯前端，与另两单可并行）**：第一批 `f8e607c2` 已验收（useState 66→52、useRef 41→39、散装 `rectification*` 归零、全量套件两侧完全相同）。本单照同一套做法搬剩下三簇：`session*` **10** 个（`useSessionManagement` 仍要解构约 40 个参数）、`profile*` **6** 个、`synastry*` **4** 个（无 hook，散在 `Home()`），目标 useState 52 → **≤36**。另修第一批留下的尾巴：`createRectificationShellSetters` 在 render 体里无记忆化 → 每帧新身份 → 多一条 `exhaustive-deps` warning（119→**120**），**正解是稳住 setter 身份、不是塞进 deps**（塞进去会每帧重拉入口摘要），本单要把 warning 降回 119。零行为变化；先分类再动手。不占 BUG 号 | 待领取 | — |
 | `TASK-api-server-backdoor-close-20260916.md` | — | **取代 decomposition 单的阶段 1（纯 Python，与另两单可并行）**：实测四处 `__new__` 的**传递闭包只有 8 个方法 / 314 行，且 0 个碰 HTTP 上下文**（占全类 4%）。所以「关后门」是一次 314 行纯搬运，不需要捆绑 2,000+ 行的体量搬运。产品拍板：**阶段 2/3 不立单**，由 `3b17c1b2` 换好的门禁（类方法数 + `__new__` 计数只许降）长期推进。唯一成功判据：`grep -c "JyotishAPIHandler.__new__"` **收到 0** 并写进合同测试。`test_api_server_security.py` 的 3,841 行断言一条不许改。不占 BUG 号 | 待领取 | — |
 | `RECONCILE-20260916.md` | — | **对账清单（不是任务书）**：状态板与现实脱节（09-15～16 那 10 份早已合入却仍写「待领取/待验收」，本轮已修正），所以另外 7 份 09-10～14 的单**不能拿 README 当证据**——它们没有 `PROGRESS-*.md`，但引用的 BUG 号都是 `resolved`。要么被别的单顺带修了没留记录，要么压根没做。每行回一个「做了/没做」即可。另附三条我已查到确定没做的证据、两条状态未闭环的、以及 BLK-001 仍红（2026-09-16 在 `4f643aa0` 复跑确认） | 待产品负责人 / 执行方回填 | — |