docs(feedback): correct the Web surface note's snapshot count

Record the measured numbers (23 snapshot files, 26 assistant messages)
instead of the estimate, and document why the E2E hovers the unrated
control before asserting the restored state.

.agents/notes/implemented/feature/2026-08-11-message-feedback-web-surface.i18n.yaml

@@ -2,5 +2,5 @@
 # side as of the last confirmed-consistent state. Both languages carry equal authority;
 # after editing either side, bring the other along and re-record with:
 #   pnpm run verify-translation-pairing --write .agents/notes/implemented/feature/2026-08-11-message-feedback-web-surface.md
-2026-08-11-message-feedback-web-surface.md: 77d21796762ce024f80fd46a7eeeea998fe94753
-2026-08-11-message-feedback-web-surface.zh.md: a6a6248c950070ebc131d285e8008313bf76d374
+2026-08-11-message-feedback-web-surface.md: 66707b4cb04f49f4fb85b364e7d1a146c4174833
+2026-08-11-message-feedback-web-surface.zh.md: 576426809457f349bcc0b1d7fcfe8054c35a6d51

.agents/notes/implemented/feature/2026-08-11-message-feedback-web-surface.md

@@ -52,4 +52,6 @@ Feedback stays invisible to the model — the sidecar reaches neither the Sessio
 
 The sidecar publishes no live frames, so a second tab's rating surfaces on reconnect or on the next conflict reply, not immediately. The note editor does not pre-check `maxNoteBytes` (8192 in the Web bundle), so an oversized note fails on save with `note-too-large` rather than while typing.
 
-Nine existing Web UI snapshots gained the two rating buttons, confirming the strip reaches every settled assistant message in the shipped composition rather than only the fixture under test.
+Twenty-three existing Web UI snapshots gained the two rating buttons across 26 assistant messages, confirming the strip reaches every settled assistant message in the shipped composition rather than only the fixture under test.
+
+A dedicated Web E2E covers rate, note, reload restore, and retract against the shipped bundle. It has to hover the unrated control after a reload before asserting the restored state, because the deferred list read is what makes the sidecar value appear — the test documents that ordering rather than working around it. Sabotaging the controller's list restore makes the spec fail, so the durability assertion has teeth.

.agents/notes/implemented/feature/2026-08-11-message-feedback-web-surface.zh.md

@@ -52,4 +52,6 @@ Web GUI 可以记录逐条消息的评价与备注。#1326 中用户可见的那
 
 该 sidecar 不发布实时帧，因此第二个标签页的评价会在重连时或下一次冲突回复时才浮现，而不是立即。备注编辑器不预先校验 `maxNoteBytes`（Web bundle 中为 8192），因此过大的备注会在保存时以 `note-too-large` 失败，而不是在输入过程中。
 
-九个既有 Web UI 快照获得了这两个评价按钮，确认这条操作栏在已发布的组装中触达每条已结算的 assistant 消息，而不仅是被测试的那个 fixture。
+23 个既有 Web UI 快照在 26 条 assistant 消息上获得了这两个评价按钮，确认这条操作栏在已发布的组装中触达每条已结算的 assistant 消息，而不仅是被测试的那个 fixture。
+
+一个专门的 Web E2E 针对已发布 bundle 覆盖评分、备注、重载恢复与撤回。它必须在重载后先 hover 未评分的控件，再断言恢复后的状态，因为正是那次延迟的 list 读取让 sidecar 的值出现——该测试记录了这一顺序，而不是绕开它。把 controller 的 list 恢复逻辑破坏掉会让该规格失败，因此这条持久性断言是有效的。