🐛 修复订阅手动检查更新无效，并同步刷新订阅列表

[CodFrm]

Checklist / 检查清单

• Fixes mentioned issues / 修复已提及的问题
• Code reviewed by human / 代码通过人工检查
• Changes tested / 已完成测试

Description / 描述

Close #1773

两个 commit，建议按顺序看：

1. c2368572 修复手动检查更新无效（issue 本身）。
2. 2278761a 订阅列表跟随后台更新同步刷新。修复 1 之后，手动检查终于能真正更新订阅了，但列表不会刷新，按钮还会一直显示「存在新版本」，所以一起修掉。

背景

手动检查更新无效。 订阅列表点「检查更新」永远显示「已是最新版本」，也不发出任何网络请求。原因是消息两端参数形状不一致：SubscribeClient.checkUpdate 发送的是 { url }，而 SW 端 requestCheckUpdate(url: string) 把整个对象当成 url，拼出的 key 是 subscribe[object Object]，查不到订阅，直接返回 false。这个错位从 MV3 重构（fcb4cc48，v0.17.0）起就存在，v1.4.0、release/v1.4、release/v1.5、main 都受影响。定时自动检查传的是字符串，不受影响。

列表不同步。 订阅列表只在挂载时拉取一次数据，SW 端也没有供页面订阅的广播。所以静默更新或在安装页确认更新之后，版本号和脚本数都要手动刷新页面才会变。另外 SW 对「已静默更新」和「已打开安装页待确认」都返回 true，UI 统一显示「存在新版本」，静默更新之后这个提示是错的。

本次改动

• SW requestCheckUpdate 改为解构 { url }，与同 group 的 install / delete / enable 一致。
• 仿照脚本列表的 installScript 广播 + subscribeMessage 模式：upsertScript 把订阅的脚本关联写回存储后，发布 upsertSubscribe，带上最终的订阅数据；useSubscribeDataManagement 订阅这条广播，按 url 就地替换行，新订阅则按创建时间插入。没有复用 installSubscribe：它发生在脚本同步之前，脚本数还是旧的，而且它是 SW 触发脚本同步用的内部信号。
• checkUpdate 返回值从 true 细分为 "updated"（已静默更新）和 "confirm"（已打开安装页），无更新或检查失败仍返回 false。状态格据此处理：updated 回到显示更新时间，confirm 显示「存在新版本」；updatetime 变化后（用户在安装页确认了更新）「存在新版本」也会复位。这个返回值只有 options 页使用，两端随同一个构建发布，不存在新旧版本混用的兼容问题。

验证

• TDD：subscribe.test.ts 新增消息边界回归测试（client → MockMessage → service），并覆盖三种返回值和 upsertSubscribe 广播；新增 SubscribeList/hooks.test.ts（行替换、新订阅插入、卸载时取消订阅）；components.test.tsx 新增状态格的 updated / confirm 两种情况。这些测试都先确认过在没有实现时失败。
• CI=true pnpm vitest run --no-coverage --shard=1/2 和 --shard=2/2：187 files / 2486 tests、187 files / 2413 tests，全部通过。
• pnpm typecheck、改动文件的 eslint / prettier 均通过。
• 真实扩展验证（pnpm run build + e2e/session.mjs 无头会话，本地 http.server 托管订阅文件，全程在订阅列表点「检查更新」，页面不刷新）：
  • 修复前的构建（subscribe.ts 取自 b6e37ccb）：显示「已是最新版本」，服务器没收到请求，checktime 没变，bug 复现。
  • 远端从 0.1.0 升到 0.2.0 并新增一个脚本：发出请求并静默更新，列表就地变为 v0.2.0 · 2 个脚本，时间显示「现在」，没有停在「存在新版本」。
  • 远端升到 0.3.0 并新增 @connect：显示「存在新版本」并打开安装页；在安装页点「更新」后，列表就地变为 v0.3.0，状态格恢复为更新时间。
  • 再点一次：显示「已是最新版本」。
• 本地非 CI 模式下的 UI 测试：b6e37ccb 基线跑整个 ui 项目就有约 90 个失败，每次运行的失败集合都不同。原因是 ui 项目配置了 isolate: false，本地又是单 worker（🔧 限制本地测试为单 worker，CI 保留并行分片 #1767），各测试文件的 vi.mock 通过共享的模块缓存相互串扰。本 PR 的测试在 CI 模式下稳定通过，但单独跑 SubscribeList/ 目录时，components.test.tsx 会受 index.test.tsx 串扰（原有的 favicon 用例同样如此）。这是既有的测试基础设施问题，本 PR 不处理。
• 范围：git diff b6e37ccb...2278761a 只涉及订阅 SW 服务、SubscribeClient、订阅列表的 hook / 状态格，以及对应测试，共 7 个文件。

[cyfung1031]

按 PR title、description 和 issue #1773 完成 rework；PICK_AUDIT 已覆蓋 RPC、订阅更新与保存、广播、列表 hook、UI 状态和相关测试。新增 5 个单一目的 commits，保留原历史：

• 052ec4dc 等待静默更新持久化后再返回成功。
• 946044fd 订阅 URL 或更新时间变化时使旧检查状态失效。
• b8281356 等待确认安装页创建成功后再返回 confirm。
• 0efaadac 串行化同一订阅的更新与存储操作，避免旧快照覆盖新结果。
• b1f61005 合并初始列表快照和后台广播，并保留最新更新时间及列表操作状态。

范围仍为这 7 个 PR 文件（Service Worker client/service、订阅列表 hook/UI 和测试）。验证结果：受影响 Vitest 2 个文件、18 tests 通过；pnpm run typecheck、pnpm run lint、pnpm run build 通过。Build 有 bundle-size 和 Monaco dependency warnings。发布 head b1f610056a94631f6a11ac69108afea42f4067c3 的 GitHub Lint、两个 test shards、四个 E2E shards、aggregate Run tests 和 License Compliance 全部通过。

Build 后的 scratch session 使用本机受控订阅 fixture（替代 PR 描述中的远端测试服务器），实际走过静默更新 v0.2.0/2 scripts、含新 @connect 的 v0.3.0 确认更新/3 scripts，以及再次检查显示 Latest Version；列表和 chrome.storage.local 分别核对。完整驱动记录在本机 e2e/scratch/pr1781-rework/，不在 PR diff 中。fixture 的 confirm.example.com favicon 有一笔 DNS 失败记录，没有阻止更新流程。

尚待人工 review（PR checklist 的 human review 项仍未勾选）。审计记录的两个边界：相同毫秒 updatetime 无法从时间戳区分先后，当前按广播到达顺序处理；若较旧的 @connect 确认页仍开着，用户之后明确点击更新仍可安装该页展示的版本。远端 head 已核对为上述发布 commit，未改写历史。