fix: 新建 V2 WebP 桌宠紧急兼容 / support newly created V2 WebP pets

[Yuimi-chaya]

中文

新版 App 新建 V2 宠物紧急兼容更新（2026-07-14）

这是已合并 PR #1484 的后续兼容修复，希望能够尽快审查并合并。#1484 修复并合并时，较新的 Codex App 已将 V2 spritesheet 从后代 <img> 改为 CSS background-image，当时实际使用的素材仍是 PNG，修复也已经通过测试。

随后新版 App 的“从零创建 V2 宠物”流程又开始生成 WebP spritesheet。已有旧宠物仍可使用 PNG 或原有渲染路径，因此实际表现会变成：刚创建的新 V2 宠物完全不响应真实鼠标，而切换回旧 V2 宠物后立即恢复。这个兼容缺口来自新版 App 后续改变了新建宠物的素材格式，并不是 #1455 或 #1484 从一开始就遗留了大量问题。

如果本更新不合并，使用新版 App 从零创建的 V2 宠物可能无法使用“桌宠跟随真实鼠标”；旧宠物继续正常工作的现象还会让用户误以为新宠物缺少 16 向素材或刷新失败。

为什么会失效

#1484 的安全探针只匹配 CSS data:image/png;base64,...，再读取 PNG IHDR 验证 spritesheet 必须为 1536×2288。这能兼容当时的新版 App，同时继续拒绝 1536×1872 V1 宠物。

本次现场检查确认，新版 App 从零创建的宠物使用 CSS data:image/webp;base64,...；Chromium 能正常解码为 1536×2288，16 向素材完整，但 PNG 专用正则会在尺寸检查前直接跳过它。Codex++ 因此按安全设计不注入运行时，而不是桌宠素材或鼠标事件本身失效。

本次修改

• 保留后代 <img> 的 V2 尺寸检测，继续兼容旧渲染路径。
• CSS 背景改用 Chromium 原生 Image.decode() 验证实际尺寸，兼容 PNG、WebP 和 blob URL，不手写不同图片格式的头部解析器。
• 按当前完整素材 source 缓存解码结果，100ms 坐标推送不会重复解码同一张 spritesheet。
• 切换宠物后 source 变化会立即使缓存失效；解码过程中发生切换时还会重新比对当前 source，避免旧素材结果多发送一次坐标。
• 仍只接受 1536×2288 V2；1536×1872 V1、未知、损坏和缺失素材继续安全拒绝。
• 不修改用户宠物文件，不改变功能入口、Windows 平台限制、交互优先级或 Computer Use 行为。

验证

• 真人复现：新建 V2 宠物不响应，切回旧 V2 宠物立即响应；重启和冷热刷新均不能绕过问题。
• 现场 CDP 检查：新宠物为 CSS WebP 1536×2288，旧探针未注入运行时；新版探针识别成功，runtime v4 接受坐标且 lastError 为空。
• 累计本地补丁安装后真人测试：新建 WebP V2 宠物真实鼠标视线跟随恢复正常。
• cargo fmt --all -- --check
• cargo test -p codex-plus-core --test cdp_bridge -j 2：77/77 通过。
• cargo check -p codex-plus-launcher -j 2
• 执行级 Node harness 覆盖 PNG/WebP/blob V2、旧 <img> V2、WebP V1、未知/缺失素材、缓存命中、V2→V1 切换及解码途中切换。

English

Urgent compatibility update for newly created V2 pets (2026-07-14)

This is a follow-up compatibility fix for merged PR #1484, and an early review and merge would be appreciated. When #1484 was fixed and merged, a newer Codex App had moved the V2 spritesheet from a descendant <img> to a CSS background-image; the active sprite format at that point was still PNG, and that fix was tested successfully.

The newer App's “create a V2 pet from scratch” flow subsequently started producing WebP spritesheets. Existing pets may still use PNG or the earlier rendering path, so the real-world symptom is now very specific: a newly created V2 pet does not react to the real mouse at all, while switching back to an older V2 pet restores gaze immediately. This compatibility gap was introduced by a later asset-format change in the new-pet flow; it is not evidence that #1455 or #1484 had many unresolved defects from the beginning.

Without this update, V2 pets created from scratch on the newer App may not work with “real-mouse pet gaze”. Because older pets remain healthy, users may incorrectly conclude that the new pet lacks its 16-direction assets or that refresh failed.

Why it fails

#1484's safety probe matches CSS data:image/png;base64,... and reads PNG IHDR to require a 1536×2288 spritesheet. That matched the newer App at the time while continuing to reject 1536×1872 V1 pets.

Live inspection now confirms that a pet created from scratch is rendered as CSS data:image/webp;base64,.... Chromium decodes it correctly as 1536×2288, with the 16-direction assets present, but the PNG-only matcher skips it before dimension validation. Codex++ therefore declines runtime injection by design; neither the pet assets nor the cursor event path is broken.

Changes

• Preserve descendant <img> dimension detection for older rendering paths.
• Validate CSS backgrounds with Chromium's native Image.decode(), supporting PNG, WebP, and blob URLs without hand-writing per-format header parsers.
• Cache the decoded result by the complete active source, so the 100 ms cursor push loop does not decode the same spritesheet repeatedly.
• Invalidate the cache when the selected pet changes, and re-check the current source after an in-flight decode to prevent one stale coordinate dispatch during a switch.
• Continue accepting only 1536×2288 V2; safely reject 1536×1872 V1, unknown, damaged, and missing assets.
• Do not modify user pet files or change the settings entry, Windows-only scope, interaction priority, or Computer Use behavior.

Verification

• Human reproduction: the newly created V2 pet failed, while the older V2 pet resumed immediately; restart and hot/cold refresh did not bypass the issue.
• Live CDP inspection: the new pet is CSS WebP 1536×2288; the old probe left the runtime absent, while the updated probe succeeded and runtime v4 accepted coordinates with an empty lastError.
• Human validation after installing the cumulative local patch: real-mouse gaze works on the newly created WebP V2 pet.
• cargo fmt --all -- --check
• cargo test -p codex-plus-core --test cdp_bridge -j 2: 77/77 passed.
• cargo check -p codex-plus-launcher -j 2
• Execution-level Node harness covers PNG/WebP/blob V2, legacy <img> V2, WebP V1, unknown/missing assets, cache hits, V2-to-V1 switching, and switching during decode.