修复大脚本与资源的消息大小限制

[cyfung1031]

Checklist / 检查清单

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

Description / 描述

背景

关联问题：Large scripts and resources can exceed Chrome’s 64 MiB extension-message limit。资源编辑器此前一次性返回所有资源，并同时传输文本与 Base64 表示；加上消息信封后，大脚本、资源集合以及其他跨上下文数据可能超过对应传输边界。

本次改动

• 为 JSON/UTF-8 与 structured-clone 相关消息增加统一的序列化字节数检查；覆盖 runtime、tabs、port、WindowMessage、CustomEvent、Firefox event-page、MessageQueue，以及服务端响应。
• 过大的服务端响应转换为有界、操作相关的诊断，避免再次发送同一个超大错误响应。
• 资源列表改为有界元数据分页；资源内容通过脚本所有权校验后的 512 KiB 原始字节块按需下载，避免在消息中重复传输全文和 Base64。
• External Access WebSocket 对入站和出站 UTF-8 frame 执行协议上限；grep 结果增加 512 KiB 总字节上限，超出时保留完整命中计数并标记截断。

实现考虑

消息大小按实际 JSON UTF-8 表示计算，structured-clone 通道另外计入 Blob、ArrayBuffer、DataView、Map 和 Set 中的二进制内容；边界测试覆盖 Unicode、JSON escaping、Base64、二进制值、精确上限和超限情形。资源块只允许资源关联脚本读取，并返回当前资源总字节数，客户端会校验 offset、length 和 total 后再组装下载 Blob。

已知限制

共享消息层的检查保护使用这些通道的现有调用方；它不会把任意业务数据改造成跨请求的通用存储协议。Chrome 64 MiB 限制、structured-clone 通道和 External Access WebSocket frame 限制分别处理，未将它们视为同一协议。未执行真实浏览器手工验证；自动化测试、类型检查、lint 和生产构建均已执行。

建议审查重点

• 检查所有 transport guard 是否在底层发送 API 调用前执行，以及超大响应的诊断路径是否仍然有界。
• 检查资源分页/分块的脚本所有权、边界校验和客户端完整性校验。
• 检查 WebSocket frame 与 grep 结果上限在 UTF-8 字节而非 JavaScript 字符数上生效。

关联

Closes #1744

验证

• pnpm test:ci — 369 个测试文件通过，4738 个测试通过。
• pnpm run typecheck — 通过。
• pnpm run lint — Prettier、TypeScript、i18n、issue-template 和 ESLint 全部通过。
• pnpm run build — Rspack 生产构建通过；仅有仓库已有的 4 个 bundle/Monaco warning。
• 提交钩子中的 typecheck、格式检查和 issue-template 检查 — 通过。

Screenshots / 截图

N/A — 本次没有改变页面布局或视觉样式。

[CodFrm]

“为 JSON/UTF-8 与 structured-clone 相关消息增加统一的序列化字节数检查”

成本是不是有点太高了，为了检查大小，还要做一次序列化，而且还只是做检查，要解决这个报错/让功能能够正常使用，还是额外的单独处理，没有意义

我觉得不如专门针对这些涉及大资源的点做优化了

“External Access WebSocket 对入站和出站 UTF-8 frame 执行协议上限；grep 结果增加 512 KiB 总字节上限，超出时保留完整命中计数并标记截断。”

动了的话，那就先这样吧

[cyfung1031]

“为 JSON/UTF-8 与 structured-clone 相关消息增加统一的序列化字节数检查”

成本是不是有点太高了，为了检查大小，还要做一次序列化，而且还只是做检查，要解决这个报错/让功能能够正常使用，还是额外的单独处理，没有意义

我觉得不如专门针对这些涉及大资源的点做优化了

“External Access WebSocket 对入站和出站 UTF-8 frame 执行协议上限；grep 结果增加 512 KiB 总字节上限，超出时保留完整命中计数并标记截断。”

动了的话，那就先这样吧

AI這樣寫很合理但你的想法也是我在想的

不然就是在sendmessage /broadcastmessage不傳
只用作通知
實際在 scripting那裡取 storage.local
然後用page event傳給inject /content

但這樣改你肯定不滿意覺得不直觀

[cyfung1031]

你用AI在這pr基礎上修改吧
這PR覆蓋的很充足但實現不是最好

或者按 #1744 重新PR也行

[CodFrm]

我移除了基础设施中的消息大小判断

512 K 太小了，限制64MB，远远达不到，容易产生不必要的浪费，扩大到了16MB