fix(webui): 聊天图片"加载成功却显示加载失败"——HTML 属性里的反斜杠转义

## 缺陷

生产截图：图片加载成功了（img 元素在、src 正确），界面却多显示一行
蓝字「图片加载失败"/>」。

根因是内联事件属性里用了反斜杠转义：

    onerror="this.parentElement.innerHTML='<span class=\"att-err\">图片加载失败</span>'"

**HTML 属性值里没有反斜杠转义** —— 那个 \" 就是引号本身，属性在
`<span class=` 之后就闭合了。浏览器切出来的是：

    onerror = "this.parentElement.innerHTML='<span class="

剩下的 `att-err">图片加载失败</span>'"/>` 变成**文本节点**直接显示。

症状极具误导性：看起来像"图片坏了"，实际图片是好的；而那个 onerror
因为语法错误**永不执行** —— 真失败时反而什么都不显示。

## 修法

不用内联属性（那要求以后每次拼 HTML 都记得转义规则），改成
**捕获阶段的事件委托**：

- error 事件**不冒泡**，只能在捕获阶段拿到（注释里写明了）
- 用 createElement + textContent 构造占位，不再拼 innerHTML 字符串
- 只处理 .chat-attachment-img，不影响正文里的 markdown 图片

## 顺带：两个类没有 CSS

`chat-attachment-img` 与 `att-err` 只出现在 JS 里，CSS 里一条都没有。
图片靠内联 style 撑着还能看，失败占位则完全没有样式。已补。

## 判据（2 条，变异验证）

- `TestChatAttachmentImgHasNoBrokenInlineHandler`：不许内联 onerror、
  必须用 DOM API、必须有 error 监听
- `TestDashboardNoEscapedQuoteInHTMLAttributes`：通用扫描，
  任何 `name="...\"...` 形态都会红（下次别人写内联事件也拦得住）

变异：把内联 onerror 放回去 ⇒ 两条同时红。

★ 写判据时踩到的坑（都已修）：判据被**自己的注释**打红（注释里必须写出
错误写法来解释），需先用已有的 stripJSComments 剥离；另外我先自己写了一个
stripJSComments，与 dashboard_js_scope_test.go 的重名 —— 应复用已有的。

## 顺带修一条脆弱判据

`TestRTChild_RapidInputCollapsesToLatest` 全量跑时偶发红
（"连发 50 条却跑了 5 轮"）。

探针查实：连发 50 条只花 ~80µs，而测试 provider 的 ChatStream **同步瞬间
返回**，两者同量级 ⇒ 消费方能在连发过程中抢到几次执行。探针显示
dropped=48，collapse 明明生效了。

所以 `Rounds > 3` 是在测调度抖动，不是测契约。改为断言**覆盖主导**
（dropped >= burst/2）。真实通话每轮几十毫秒，连发微秒级，生产里
"轮次≈1" 自然成立。

变异验证：让 dropped 不计数 ⇒ 判据红（dropped=0（连发 50 条））。

go build/vet/gofmt 干净；go test ./... -count=1 -race = 62 ok / 0 FAIL / 0 RACE

internal/agent/core/rtchild_r11_test.go

@@ -188,10 +188,32 @@ func TestRTChild_RapidInputCollapsesToLatest(t *testing.T) {
 	if !ok {
 		t.Fatal("实例不存在")
 	}
-	if st.Rounds > 3 {
+	// ★ 判据是「**绝大多数输入被覆盖**」，不是「轮次必须 ≤3」。
+	//
+	// ## 为什么不能只看 Rounds（实测：本判据曾偶发红）
+	//
+	// rtCountingProvider 的 ChatStream **同步瞬间返回**（缓冲 2 的 channel
+	// 里塞好就 close），于是消费循环的每一轮是微秒级；而连发 50 条本身
+	// 也只花 ~80µs（探针实测）。两者同量级 ⇒ 消费方有机会在连发过程中
+	// 抢到几次执行，轮次可能到 5。
+	//
+	// 这不是缺陷：探针实测 dropped=48、rounds=2，collapse 明明生效了。
+	// 真实通话里每轮要几十毫秒（LLM 往返），而连发是微秒级，
+	// 所以"轮次≈1"在生产里自然成立 —— 用微秒级 provider 去要求它，
+	// 是在测调度抖动，不是在测契约。
+	//
+	// ## 真正该钉的是什么
+	//
+	// 契约 1/3 的核心是「**不排队**」：绝大多数输入必须被**覆盖丢弃**，
+	// 而不是逐条被处理。所以断言 dropped 占绝对多数。
+	if st.Rounds > burst/4 {
 		t.Fatalf("连发 %d 条却跑了 %d 轮 —— rtSlot 退化成了队列（契约 1/3：最新者胜、不排队）",
 			burst, st.Rounds)
 	}
+	if st.Dropped < burst/2 {
+		t.Fatalf("dropped=%d（连发 %d 条）—— 绝大多数输入应被覆盖丢弃，"+
+			"而不是逐条处理（契约 3：不吃队列、不补偿）", st.Dropped, burst)
+	}
 	if st.Dropped == 0 {
 		t.Fatal("连发 50 条但 dropped=0 —— 覆盖没有发生，或计数器没接线")
 	}