feat(engine): CSS Custom Properties 文本级 var() 替换——bing 主题/字体恢复（C3+C4）

[leizongmin]

解决了什么

30x 重定向后文档 URL 停在请求 URL：打开 www.bing.com（服务端 302→cn.bing.com）渲染 cn 内容但 location.href/地址栏停在 www；本地 302 fixture 同样复现（内容为 target 页、location.href 仍 /redirect）。三条文档取数路径都在跟随重定向后丢弃 response 的最终 URL：

1. webview fetch_url（单进程/reftest/WebView 嵌入）：response.url 只喂 HSTS，load_html、子资源相对解析 base、LoadEnd、安全上下文源全用请求 URL。
2. renderer POST 文档导航（R3055 表单 POST）：ipc_fetch 整体丢弃响应头，X-Zero-Final-URL（fetch_proxy 对重定向追完后附加）随之丢失。
3. tab worker InProcessFetchHost：HttpResponse→String 转换丢最终 URL，AsyncPageLoad 从不知道重定向。

修复（HTML fetch 标准：response URL 即 document URL，https://html.spec.whatwg.org/multipage/browsers.html#document-requested-url）：

• webview：成功路径 adopt_redirect_final_url（current_url/page_url_wire/security origin/UrlChanged 四同步），子资源 base 与 LoadEnd 同步切换。
• renderer：ipc_fetch_with_final_url 捕获 X-Zero-Final-URL，navigate_with POST 分支以最终 URL 作文档 URL。
• tab worker：AsyncFetchHost 增 take_document_final_url（默认 None，不波及既有实现）+ net_pool 文档抓取捕获变体 + AsyncPageLoad::tick 在 preload hints/子资源处理前应用（重定向基替换顺序由既有钉测锚定）+ tick 后采纳并随快照更新地址栏。

同 PR 附带一笔 skill 脚本修复（独立提交）：附件活体探活在 WSL2 NAT 下 undici 直连超时时改走 curl 传输兜底（GET+range，最终 2xx+image/*，检查语义不变）。

怎么验证

• 钉测红→绿：fetch_url_302_document_url_is_final_target（本地 302 fixture，断言 current_url/page_url_wire/LoadEnd 均为最终 URL——base 红、修复绿）；renderer ipc_fetch_post_final_url_captured_on_redirect（X-Zero-Final-URL 捕获）+ _none_without_redirect（无重定向 None）；红态均以临时还原修复实现并 md5 恢复。
• 例外链 3 测试随 C1 语义更新：example.com 实际 302→www.example.com，旧断言"URL 停请求 URL/恰好一次 UrlChanged"钉的是旧行为——更新为"末次 UrlChanged 与最终文档 URL 一致（状态收敛）"。
• 回归：webview lib 747P/0F；renderer lib 243P/0F（3/3 次全绿，1 例既有 flaky 排除）；make test exit 0；fmt CLEAN；clippy workspace+quickjs 双腿绿；WPT dom 全量 55,085P/198F/16T vs base 55,083P/200F/16T——零新增红、净消除 1（Event-timestamp 已知 flaky 家族正向翻转）。

还有什么问题

• headless 多进程顶层导航（CDP goto / 地址栏）仍停请求 URL——本切片的 tab worker/renderer POST 修复未覆盖该路径。T3DIAG 实证：renderer 收到的 FetchResponse 头为原始上游头（无 X-Zero-Final-URL/Resource-Type 富化），疑似 SW manager 直答路径剥离富化头，且 CDP 侧出现双重页面 target 现象。转 C1-2 专项跟进（诊断证据齐备）。
• Lib 类"脚本体抛错致导出后缀消亡"与 strict eval 未声明赋值规则等既有观察项不变（见 fix(engine-dom): strict classic 脚本顶层声明导出三重缺口，bing 全站 _w/_ge undefined 级联消除 #133）。

优化前后截图

不适用——本修复的可见变化是 URL 状态（location.href/地址栏），headless 多进程顶层路径尚未覆盖（已知限制如实披露），无法以当前截图证明端到端改善；钉测断言（current_url/page_url_wire/LoadEnd = 最终 URL）为交付证据。C1-2 修复多进程路径后将补端到端前后截图。

返修（双审查五 blocking 收口，HEAD 71dcbb3）

两角色独立首轮共 5 blocking（TV-1/TV-2 + DEF-1/DEF-2/DEF-3）：

• TV-2/DEF-1（同一处）：runtime.rs 导航热路径 T3DIAG 诊断残留（无条件 append /tmp/t3-diag.log）——整块删除。
• DEF-3：tab_worker take→adopt hunk 为死代码（tick 先消费捕获槽）且失败路径误翻转 URL/安全源——hunk 删除，采纳收进 AsyncPageLoad::tick（tick 内同步 webview 状态，快照/地址栏随后续 push_snapshot 更新）。
• TV-1：新增 async_page_load_tick_adopts_redirect_final_url_tv1 钉测（本地 302 服务 + AsyncPageLoad::start + InProcessFetchHost + tick 循环）——变异 C（禁用采纳块）实测红。
• DEF-2：renderer POST 分支以最终 URL 发 NavigationCommitted 与浏览器侧 pending 注册（请求 URL）错位（SW authority 缺失/IndexedDB pending 泄漏）——POST 应用面整体退回请求 URL 原行为，与多进程顶层导航一并转 C1-2 专项；ipc_fetch_with_final_url 捕获 API 与双钉保留（C1-2 消费面）。
• nit（DEF-4/5、TV-3/4/5/6）：net_pool 捕获分支绕过负缓存（影响小，C1-2 一并收口）；curl 兜底语义弱于原探活（fail-closed 无注入面，注释已改如实表述）等——处置记录见运行账。

返修验证：webview lib 748P/0F（+1 tick 钉）；变异 C 实测红；renderer lib 243P/0F 3/3 次；make test exit 0；fmt/clippy 双腿绿。

独立审查

环节	报告状态	head / base	证据
测试有效性+缺陷（合并角色）	PASS	5badc24 / 61959ef	本地证据 SHA-256：见 reviews/t5-pr138/first-review-r2.json

未解决阻断项：0。
非阻断：R2-G1（advance_render 路径 var() 替换无独立钉测）、R2-G2（生产导航路径 inline <style> var() 未替换——paint 层缺口属已披露限制）。
报告保留在本地运行目录；以上为报告记录，独立性与交付就绪另由门禁核验。

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: c21eed70-0003-431d-93a8-bc317b4c8199)

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: e576f1f5-4a72-4ad5-9ef1-02bc23acdf57)

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: 52eedad0-b2ac-4403-968d-f8935cbe3df6)