feat(collect): 纯离线生成打通 1ms 签到文字点选 —— errorCode=0 收口

做了什么:
- 新增 tcaptcha/tdc_values.py: 37 个语义名的取值生成器（静态画像 / 会话量 /
  每次采集量三层）+ build_plain 四段组装 + generate_collect 纯离线出包
- crypto: 新增 generate_telemetry(mode="python_values")；轨迹生成统一到
  trajectory_points()（首点绝对坐标 + 增量 + 固定收尾 [1,1,12]）
- crypto.split_collect_segments 重写: pad 只有 1 个空格时旧 ` {2,}` 判据会漏段，
  且 UA 串里的普通空格会假阳性 —— 改为「模 24 算术 + 不落在 JSON 字符串内部 + 结构校验」
- tools/tdc_modules: trajectory 指纹原先指向只做 JSON.stringify 的模块，改为
  mouseMoveEvent/touchStartEvent（真轨迹模块），37/37 不变
- client 默认 telemetry_mode 改为 python_values
- 新增 scripts/verify/{align_session,audit_names,verify_values,verify_offline,send_test}.py
  与 tools/{cdp_collect,cdp_dump_scripts,tdc_profile}.py

为什么:
- 账本 #40「谁在发 HTTP 是 12 的剩余自变量」被推翻。同 aid/同客户端/同求解器、
  答案都对，只换 collect 构造方式: 本次会话构建生成 -> 0 (4/4)，
  旧模板回填 -> 12 (2/2)。真因是 collect 必须与本次会话构建同源。

怎么验证:
- .venv/bin/python -m tcaptcha.selftest  全绿（含新增四段切分与纯离线闭环回归）
- scripts/verify/verify_values.py        4 份真机明文 152/152 逐槽全等
- scripts/verify/verify_offline.py       逐槽全等 + 分段几何一致
- scripts/verify/send_test.py --mode python_values  1ms 签到页文字点选 errorCode=0 x4

tcaptcha/client.py

@@ -148,26 +148,32 @@ class TencentCaptchaClient:
         min_posterior: float = 0.95,
         pow_timeout: int = 4000000,
         inter_attempt_delay: float = 0.25,
-        telemetry_mode: str = "python_keyed",
+        telemetry_mode: str = "python_values",
         proxy: Optional[str] = None,
         cookies: Optional[dict] = None,
         transport: str = "httpx",
         impersonate: Optional[str] = None,
     ):
         """
-        telemetry_mode 决定 collect/eks 怎么来 (见 tcaptcha.crypto.generate_telemetry), 只走纯算:
+        telemetry_mode 决定 collect/eks 怎么来 (见 tcaptcha.crypto.generate_telemetry):
 
-          * "python_keyed" (默认): Node 只从本次构建的 tdc.js 里提取 XTEA 密钥字;
-                                   明文组装 / 轨迹 / 时间戳 / 加密 / 编码全部在 Python 完成。
-          * "python":              完全不调用 Node, 直接用内置 DEFAULT_KEY
+          * "python_values" (默认, 2026-10-12 起): **纯离线**按**本次会话的** tdc.js 生成整颗
+                                   collect —— 37 个语义名 -> 38 槽取值 -> 4 段明文 -> 4 段加密，
+                                   零 Node、零真机明文。"必须用本次会话的构建"这一点是实测出来的
+                                   分水岭: 同一 aid 下它 3/3 拿 0, 而模板回填 2/2 恒 12
+                                   (har/1ms_dianxuan/PROGRESS.md 已知 #58/#59)。
+          * "python_keyed":        明文来自仓库里的**成功样本模板回填**
+                                   (generate_collect_success): 槽序来自**另一份构建**、
+                                   取值来自**另一台设备** -> 1ms aid 上实测恒 12。
+          * "python":              完全不调用 Node, 用内置 DEFAULT_KEY + 同样的模板回填
                                    (仅对不校验遥测的宽松 aid 有效)。
 
-        关于 errorCode=12 (实测 2026-10-11, 见 har/1ms_dianxuan/ANALYSIS.md §7):
-          1ms.run aid=195672344 在答案正确时返回 12, 且与遥测后端无关 ——
-          python / python_keyed / node / browser 四种后端、4 个不同省份出口 IP、
-          9 分钟静默后单发, **全部都是 12**。所以 12 不是遥测/环境/IP 问题,
-          不要再走"补环境"或"换 IP"的路; 真正的变量 (登录态 / 真实验证码页面上下文)
-          尚未被单变量实验区分。
+        关于 errorCode=12 (**2026-10-12 已收口, 旧结论已推翻**):
+          真因不是"环境/IP/请求方", 而是 **collect 没有用本次会话的那份构建生成**。
+          同 aid / 同客户端 / 同求解器、答案都正确, 只换 collect 构造方式:
+          python_values -> 0 (3/3), python_keyed (旧模板回填) -> 12 (2/2)。
+          见 har/1ms_dianxuan/PROGRESS.md 已知 #58/#59。
+          附带一条方法学: **答错一律 50/9**, 所以任何用"答错"做的对照都没有区分度。
 
         cookies: 可选, 逐条写入 captcha 域 (turing.captcha.qcloud.com) 的 Cookie 头。
           成功样本 (har/签到成功-1.har) 的 captcha 域请求带着腾讯云登录 cookie