docs: document monitor check title sanitization

docs/reference/observability.md

@@ -37,6 +37,8 @@ Web 哨兵 dashboard/API 展示问题的第一事实源是 sentinel runner 的 `
 
 `web-probe sentinel dashboard verify` 必须区分页面渲染证据和 API 可达性证据。远程浏览器已经拿到 HTML shell、`data-monitor-ready=true`、目标 run/曲线 DOM 和内存/request 图表时，页面二次 `fetch("/api/*")` 遇到瞬时 `ERR_NETWORK_CHANGED`、abort 或同类浏览器网络抖动，不得直接归类为 dashboard render failed；应优先保留浏览器 DOM 证据，并用受控 runner service API 读取 `/api/overview`、`/api/runs` 和 `/api/runs/{id}` 作为显式 `service-fallback` 证据。fallback 只能修正 verifier 证据来源和合同判断，不能遮盖真实页面 shell 未 ready、图表未渲染、sentinelId/route 不匹配、目标 run 不一致、页面 error、horizontal overflow 或 service API 本身失败。
 
+monitor-web 的登记标题和用户摘要使用不同净化边界。登记标题来自 check catalog、runner `/api/runs/{id}` 或 `/api/errors/{errorId}` 的 `displayTitleZh`、`errorTitleZh`、`checkTitleZh` 和 `check.titleZh`，只应过滤空值和 `未登记监测项` 占位；不得套用会屏蔽 `trace`、投影、Shell、API 等内部词的摘要净化规则。摘要、根因和处理建议仍必须经过用户可见文本净化，避免把内部 trace、DOM、HTTP、runner 或 analyzer 细节直接当作面向用户的处置文案。
+
 Web 哨兵 findings 可见性要同时核对 runner API 和已有 observe artifact。若某个 run 的公开 `/api/report?view=findings&run=<id>` 只显示 WBC-003，但 `web-probe sentinel report --run <id> --view findings --raw` 能从 `analysis/report.json` 读出 red/amber analyzer findings，根因是索引或 artifact 可见性遮盖，不是业务没有产生 warning/error。此时应回填或重建这条既有 run 的 report index，并保留原有 report views；不要通过启动新的哨兵 run 来解释旧记录。
 
 Web 哨兵 check code 是排障和验收合同，必须保持语义单一且确定。一个 code/id 只能对应一种可执行处置路径；如果一个 finding 可能同时表示“没有采集到业务轮次”“目标轮次缺 traceId”“trace rows/projection 缺失”“Final Response 为空但仍在运行/取消”“Final Response 为空且已失败/终止”等多种状态，就必须拆成多个固定 code/id。不得用同一个 code 的动态标题、动态 summary 或 rootCause 文案来承载多种互斥语义；动态字段只能补充证据，不能改变 code 的语义。`quick-verify` 只能作为运行阶段或证据上下文，不能作为 root-cause code 的宽泛语义；账号/会话命令失败、observer start/stop/cleanup、turn-summary、trace-frame、report analyze、无采样和 artifact/index 缺口必须各自用固定 code 表示。