🐛 fix(display): 重做 SparkBot 待机眼睛连贯动画

[ZhaoXingPeng]

一句话结论：SparkBot 待机屏保已改为全画布 14 帧连贯动画，双眼进一步放大并拉开间距，眼珠左右移动，睁眼到眯眼自然过渡；整体 UI 继续下移 6px 避开外壳遮挡。

一句话动作：请按实板证据审阅并合并本 PR；合并后关闭 Issue #341。

Fixes #341

验证

• GIF 逐帧解析：96x96、14 帧、每帧 80ms；每帧为完整画布，避免差分帧残影。
• 逐帧视觉检查：左右眼边界约为 x=2..37 与 x=59..94，眼距进一步增加；覆盖左、中、右眼珠位置及半眯、闭眼、半睁、睁眼过渡。
• Host CTest：80/80 通过。
• Python SparkBot 资源测试：11 项通过，1 项按现有环境跳过。
• Format、架构、公共 API、双端契约与 Profile 校验通过。
• ESP-SparkBot 固件增量构建通过；应用与 assets 刷写至 /dev/cu.usbmodem14101，均 Hash of data verified。
• 实板启动日志确认 SPARKBOT_ASSETS_MMAP_OK=1、SPARKBOT_COMMON_FONT_ASSET_OK、viewport_xywh=12,6,216,120。
• 实板串口连续确认多轮 SPARKBOT_GIF_LOOP asset=idle_eyes，屏保持续解码。

风险

• 本次只改显示资源、布局参数和资源断言，不改语音、日程、提醒、IM 或分区/NVS。
• 实板串口仍可见既有 Linx WebSocket 断线和 IM 401 degraded；与本 PR 显示改动无关，已在测试记录中区分。

AI assistance

• AI 协助生成资源变换候选、更新清单和测试；人工逐帧检查资源尺寸与节奏，复核 diff，并在 SparkBot 实板刷写与明文串口日志中验证。

[fennoai]

Review conclusion

Reviewed the complete fixed diff for the SparkBot asset manifest/GIF contract, the 6px product viewport offset, and the corresponding host/Python assertions. I found no actionable correctness, compatibility, or reliability regressions introduced by this PR.

Verification performed locally: python3 -m unittest tests/python/test_sparkbot_assets.py passed 11 tests with 1 environment-dependent skip; scripts/build_sparkbot_assets.py reproduced the manifest asset image SHA-256 and 416948-byte image size; git diff --check passed. The repository had no existing host build artifacts, so the C++ host binaries were not rerun locally.

[ZhaoXingPeng]

本轮验收记录（2026-08-21）

本轮将 SparkBot 待机双眼从约 32px 宽放大到约 36px 宽，并将边界调整为左 x=2..37、右 x=59..94；保留 14 帧、80ms 节奏、眼珠左右移动和自然眯眼过渡。

验证结果：

• Host CTest：80/80 通过。
• Python SparkBot 资源测试：11 项通过，1 项按现有环境跳过。
• scripts/check_format.sh：clang-format、Ruff format/check 全通过。
• python3 scripts/firmware.py build esp32s3-esp-sparkbot：通过，应用分区余量 11%。
• /dev/cu.usbmodem14101 刷写：应用 0x10000 与 assets 0x300000 均 Hash of data verified。
• 重启串口确认：SPARKBOT_ASSETS_MMAP_OK=1、SPARKBOT_COMMON_FONT_ASSET_OK、viewport_xywh=12,6,216,120。
• 实板连续日志确认多轮 SPARKBOT_GIF_LOOP asset=idle_eyes，待机动画持续解码。

环境说明：串口仍可见既有 Linx WebSocket 断线和 IM 401 degraded，它们与本轮显示资源变更无关。

[ZhaoXingPeng]

唤醒故障复测与修复（2026-08-21）

问题定位：本地 MultiNet 已稳定输出 WAKE_DETECTED word=你好牛牛，但 Linx WebSocket 在上行写失败后进入断线；旧 TX 失败路径又调用 esp_websocket_client_stop/start，与 ESP-IDF 内建自动重连并发，实板出现 Error create websocket task，导致 VoiceSession 长时间不在 Ready，后续唤醒返回“语音会话当前不能通知本地唤醒”。

修复提交：92ecce2 🐛 fix(linx): 修复发送失败后的唤醒重连

• 删除 TX 任务中的竞争性 stop/start。
• 保留失效连接的媒体与控制队列清理，避免旧帧穿过重连边界。
• 由 disable_auto_reconnect=false 的 ESP-IDF 客户端任务单独负责重连。

本地验证：Host CTest 80/80、格式/Ruff、ESP-IDF 6.0.2 SparkBot 构建均通过。百炼 TTS 返回 20571 字节，STT 请求成功；“你好牛牛”云端 STT 误识为“你好，牛六”，而板端本地 MultiNet 日志已正确识别唤醒词。

实板复刷暂被 USB 设备枚举中断：/dev/cu.usbmodem14101 在刷写前消失，未执行不完整写入。设备重新枚举后将补充应用/资源刷写、断线自动恢复、待机唤醒和全链路串口明文证据。

[ZhaoXingPeng]

唤醒故障已登记为 Issue #345：https://github.com/1024XEngineer/VoiceLife/issues/345。当前修复提交 92ecce2 继续在本 PR 的单一开发分支验证，待 USB 设备恢复枚举后补齐实板复刷与唤醒验收。

[ZhaoXingPeng]

提交正文已补齐 Issue 关联并重写：修复提交当前为 e562313 🐛 fix(linx): 修复发送失败后的唤醒重连（此前评论中的 92ecce2 为 amend 前 SHA，代码内容一致）。

[ZhaoXingPeng]

唤醒复测记录（2026-08-21）

结论：修复提交 e562313 的本地回归与百炼真实模型调用均通过，但 SparkBot 当前未枚举为 USB 串口，尚无法完成本次真机唤醒注入验收。

已完成：

• scripts/run_host_tests.sh：80/80 通过；包含 VoiceSession、本地唤醒、Linx transport、日程 SQLite、提醒与 IM 相关用例。
• scripts/check_format.sh：通过。
• 百炼 cosyvoice-v3-flash 合成“你好牛牛”成功：20,571 bytes，首包 703ms，测试音频为 /tmp/wake-你好牛牛.mp3。
• 百炼 qwen3-asr-flash 对该音频调用成功，返回“你好，牛六”。这是云端 ASR 的同音识别变体，不能替代板载 MultiNet 的唤醒判断。
• 当前 /dev/cu.usbmodem* 不存在，USB 枚举中也未发现 Espressif/SparkBot。因此没有伪造串口、屏幕或唤醒成功证据。

待设备重新插拔并重新枚举后，按此顺序补测：刷写应用与 assets 并校验 Hash；确认 WAKE_WORKER_ARMED；播放上述百炼音频，确认 WAKE_DETECTED word=你好牛牛、local_wake_ack_requested、tts_first_audio；等待屏保后重复；再验证一次 LINX_TX_SEND_FAIL ... await client auto-reconnect 后恢复 transport_connected 与 provider hello completed。

[ZhaoXingPeng]

Linx/MCP 断线真机诊断（2026-08-21）

结论：硬件链路正常，问题集中在 Linx WebSocket 与 MCP tools/list 响应的交互；目前不能归因于 SparkBot 音频、存储或显示硬件。

证据：

• SparkBot 实板反复完成 Wi-Fi、transport_connected、MCP 请求处理和自动重连；音频统计持续增长，in_i2s_err=0、out_i2s_err=0、in_drop=0。
• 每次连接固定收到 MCP_REQUEST_QUEUED bytes=518 与 bytes=46，两次均 MCP_TOOL_EXECUTED ... result=1；当前注册工具数为 6，不是工具调用风暴。
• 随后固定在发送 LINX_TX_SEND_FAIL sent=0 want=6275 时失败，底层为 transport_poll_write(0) / esp_transport_write() returned 0。
• 详细事件日志连续 24 次一致：type=0 close=0 handshake=0 tls_valid=0 ...。ESP-IDF 1.8.0 在写失败日志时尚未设置 error_type，因此 type=0 不是“无错误”；底层同一时刻报告 errno=11 (EAGAIN)。
• 受控实验将 WebSocket 缓冲提高到 8192、TX 等待提高到 5 秒，仍在同一 6275 字节响应失败，排除单纯分片和单纯 1 秒超时。
• 同一实验中实板明确出现 WAKE_DETECTED word=你好牛牛、local_wake_ack_requested 并进入屏幕“聆听中”，证明硬件唤醒和显示联动正常。

判断：6 个工具本身不是数量过多；但工具列表响应触发了 Linx 端/兼容层的读取背压或协议处理异常。下一步应在 Linx 侧确认 tools/list 响应限制/解析错误，或做最小工具列表 A/B（0/1 个工具）以定位具体 schema；不应继续从硬件侧排查。

本轮提交：3f199b1 🐛 fix(linx): 增强 WebSocket 错误诊断并修正未初始化字段。验证：Host CTest 80/80、scripts/check_format.sh、ESP-IDF SparkBot 构建与应用刷写 Hash 校验通过。