test(1ms): 逐条单变量排除 errorCode=12 的已知自变量 (cookie / 传输指纹 / 头保真 / collect)

做了什么
- 新增 tcaptcha/http_transport.py: curl_cffi(Chrome) 传输层壳, 对上层暴露 httpx.Client 同款
  get/post/close; TencentCaptchaClient 增加 transport="httpx"|"curl" + impersonate 参数。
- client.py 按真实抓包(har/签到成功-1.har)逐 endpoint 保真请求头:
  * prehandle/tdc.js/getcapbysig: Sec-Fetch-Dest=script/image + Mode=no-cors +
    Storage-Access=active + captcha 域 cookie, Referer 为 site-origin / gtimg;
  * getsig/verify: empty/cors + Origin gtimg, 且 **不带** cookie (SameSite=Lax 实测如此)。
  cookie 由全局头改为按调用点附加 (此前 verify 也带, 与真实浏览器不符)。
- 新增 scripts/experiment_transport_ab.py: 只改传输层的单变量 A/B。

为什么 (AGENTS §2.1 / §5.7)
- 抓包里 1ms 的真机成功样本(errorCode=0)与真机失败样本(50/50/9)证明: 12 是"请求方身份"判定,
  与答案/载荷无关 —— 需要把客户端与真机的每一处可测差异逐条单变量掉。

怎么验证 (2026-10-11 实测, 全部仍 12)
- 真实 cookie 值 (uin/skey/qcmainCSRFToken/intl) -> 12 (H3 用真值再次排除)
- curl_cffi impersonate=chrome (JA3/JA4 + HTTP/2 + 头序) + 真实 cookie -> 12 (传输层排除)
- curl_cffi + 逐 endpoint 头保真 (Sec-Fetch-*/cookie 位置) -> 12 (头保真排除)
- 我们的 collect 明文与 1ms 真实成功样本逐字节同构 (同 1353B/同字段序/同取值) -> 12 (内容排除)
- 反向: 用纯 Python 提取的密钥成功解密 1ms 真实成功样本的 collect -> 密钥链路对真机样本成立
- .venv/bin/python -m tcaptcha.selftest 全绿

账本 har/1ms_dianxuan/PROGRESS.md: 已知 #23~#25; 已排除表新增四行; 下一步改为 (a) 真机桥接保底 /
(b) identity_context 研究项。

har/1ms_dianxuan/PROGRESS.md

@@ -53,6 +53,9 @@
 | 20 | **opcode 表可从该构建解释器源码推导**：主循环 `X[Y[Z++]]()` 的 `X` 就是 handler 数组，下标即 opcode；handler 规范化指纹可跨构建精确匹配 | 6/6 份构建 **58/58 handler 精确匹配**、0 未识别（`tcaptcha/tdc_opcodes.py`）| 确证 |
 | 21 | **密钥字闭包只写"被 XTEA 闭包捕获的那个数组"**；脚本同时算了两套 4 字（真 + 诱饵），靠**两层捕获链**区分：字闭包捕获的 B 帧寄存器 `w_src`，经"定义 B 的那个闭包"的 caps 映射到 G 帧后须 == XTEA 闭包捕获的寄存器 | core/root/1ms×3/实时新抓 全部选对；诱饵组按同规则被排除 | 确证 |
 | 22 | **纯 Python 静态提取 XTEA 密钥成功，零 Node** | `tcaptcha/tdc_key.py`：6/6 份构建与 Node 插桩 `extract_xtea_key` **逐字一致**；含 2026-10-11 现场新抓的 `tdc.js`（`har/1ms_dianxuan/live/tdc_fresh.js`，77967B，密钥 `[1397244740,1799507557,1399740484,1516463189]`）| 确证 |
+| 23 | **纯 Python 密钥能解密 1ms 真实成功样本的 collect** | 用 `har/签到成功-1.har` 里那次 ec=0 之前的 tdc.js 提密钥 → 解出该次 collect 明文 `{"cd":[2560,"MacIntel",...` 1353B；且与 `models/success_collect_template.b64` **逐字节同构**（仅轨迹/时间戳/盐被回填）| 确证 |
+| 24 | **1ms 真实成功链路已完整解析** | prehandle(带腾讯云登录 cookie) → tdc.js → getcapbysig → verify **ec=0**(ticket `tr03…`) → `POST /api/v1/mall/checkin`，body = `{captchaTicket:{provider,data:{ticket,randstr}}, sessionUuid, identity_context}`；`/api/v1/captcha/params` 的 body 带 `identity_context`(`emctx1.<b64>.<sig>`) | 确证 |
+| 25 | **真实浏览器对 verify 从不吃 12** | `点选.har`(同一 cookie/同一 aid) 三次 verify = 50/50/9；`签到成功-1.har` = 0。而我们**任何**客户端形态都是 12 → 12 是"请求方身份"判定，不是答案/载荷 | 确证 |
 
 ---
 
@@ -83,6 +86,10 @@
 | 轨迹 dt 太小是 12 的"直接原因" | 换成真实 ms 分布后仍 12（E6） |
 | **opcode 数值是跨构建固定的 VM 常量** | 6 份构建实测 pc0 的 `SET_STACK_LEN`/`JUMP` 数值全不同（见已知 #19）；`tools/tdc_disasm.py` 里固化的表**只对 core_js 有效**，已改为"可注入按构建推导的表" |
 | **"密钥字必须靠 Node 插桩才能拿到"** | `tcaptcha/tdc_key.py` 纯 Python 零 Node 复算，6/6 构建与 Node 逐字一致（已知 #22）→ Node 降级为兜底 |
+| **H3（captcha 域腾讯云登录 cookie）能解决 12** | 用**抓包里的真实 cookie 值**（uin/skey/qcmainCSRFToken/intl）重跑，仍 12（`scripts/experiment_h3_cookie_ab.py --only b`，2026-10-11）→ 与早期结论一致，H3 确凿排除 |
+| **HTTP/TLS 传输指纹是 12 的自变量** | `curl_cffi`(impersonate=chrome: JA3/JA4 + HTTP/2 + Chrome 头序) + 真实 cookie，仍 12（`scripts/experiment_transport_ab.py --only b`）→ 传输层排除 |
+| **请求头保真度是 12 的自变量** | 按真实抓包逐 endpoint 保真：资源 GET 用 `Sec-Fetch-Dest=script/image` + `Mode=no-cors` + `Storage-Access=active` + cookie，POST 用 `empty/cors` + Origin 且**不带** cookie；仍 12 |
+| **collect 明文结构/取值是 12 的自变量** | 我们的 collect 明文与 1ms 真实成功样本**逐字节同构**（同 1353B、同字段序、同取值，仅回填轨迹/时间戳/盐），仍 12 |
 
 ---
 
@@ -115,9 +122,13 @@ TencentCaptchaClient(telemetry_mode="python_keyed")     # 默认
    残留增强项（非阻塞）：① 若服务端改了 handler 语义，`tdc_opcodes.derive_opcode_table`
    会抛"指纹未识别"，此时应更新参考指纹而非改定位逻辑；② 抗"多套诱饵数组 >2 层捕获"的
    兜底（当前两层已覆盖实测全部 6 份）。
-1. **拿下 1ms 的 12**：做账本 §7.5 的**单变量实验** ——
-   (a) 给 captcha 域带上成功样本里的 `uin/skey/qcmainCSRFToken/intl` cookie（已做，H3 已排除）；
-   (b) 登录态真页面触发 vs 未登录触发。二选一即可闭合。
+1. **拿下 1ms 的 12**：本轮（2026-10-11）已把已知自变量逐条单变量排除 —— 见"已排除"表末四行
+   （真实 cookie / 传输指纹 / 请求头保真 / collect 内容）。**剩余两条可执行路径**：
+   (a) **保底（建议先做）**：账本 §2.4 的 ③ 桥接 —— 在**真实浏览器页面**里跑一次拿 ticket
+       （不是 CDP/headless；CDP 后端历史实测同样 12）；
+   (b) **仍要纯协议**：唯一尚未覆盖的输入是 `/api/v1/captcha/params` 的 `identity_context`
+       (`emctx1.<b64>.<sig>`) —— 但它只发给 **1ms 后端**、不进 Tencent 的 verify，
+       因此**不能单独解释** 12；除非 1ms 后端用它把业务会话与 Tencent 侧绑定（需一次对照实验验证）。
 2. **补齐新版明文字段语义**：对照 10+ 份实时模板做差分。
 3. **实现 2408 图标点选**：按 1ms 图标类别重训 `yolo_detector` + `icon_classifier`。
 4. **实现滑块 (2401/2402)**：模板匹配找缺口 + 生成滑动轨迹。