feat: [filesystem] 增加文件系统，文件前缀的自定义能力

[Hierifer]

• 开发者可以通过注入容器 VIRTUAL_FILE_PREFIX 来修改文件前缀
• FileSystem 对象支持 iterable

[dos1in]

问题

[P1] 自定义文件前缀没有贯通容器和文件系统实现

文件：fe/packages/service/src/api/core/file/index.js:3

当前代码只使用 globalThis.__VIRTUAL_FILE_PREFIX__ 生成 wx.env.USER_DATA_PATH，但没有形成完整的跨层配置链路：

• Android、iOS、HarmonyOS 和 Web 文件解析器仍然只识别硬编码的 difile://。
• 四端容器启动逻辑都没有注入 __VIRTUAL_FILE_PREFIX__。
• Web 端 service 运行在独立 Worker 中，宿主设置 window.__VIRTUAL_FILE_PREFIX__ 不会自动传入 Worker。

因此，默认情况下该变量只能得到 difile://；即使通过非公开方式提前注入 custom://，wx.env.USER_DATA_PATH 会变成 custom://usr，但随后使用该路径调用 writeFile、saveFile 等 API 时，仍会被容器判定为非法路径。

建议将文件前缀纳入四端公开容器配置，并在加载 service.js 前完成注入；文件解析器、默认返回路径及 Web Worker 启动配置必须使用同一前缀。同时增加“自定义前缀下使用 wx.env.USER_DATA_PATH 写入并读取文件”的跨层测试。

[P2] 提交的 JSSDK 是 development 构建产物

文件：shared/jssdk/main.zip（二进制文件，无行号）

解压比较：

文件	原产物	PR 产物
service.js	144,138 字节	291,842 字节
pageFrame.js	271,914 字节	598,902 字节

PR 产物还保留了未压缩代码和 development 调试分支。在该 head 上重新执行 production 构建后，pageFrame.js 恢复为 271,914 字节，并且哈希与原包完全一致，说明这部分二进制变化仅由构建模式导致。

由于 shared/jssdk/config.json 已升级到 1.0.32，合入后客户端会主动解压并使用该开发包。建议使用 production 模式重新构建并生成 main.zip。

验证情况

• Frontend Lint、Frontend Tests、iOS Unit Tests 均通过。
• 本地 Service 测试通过：45 个测试文件、477 项测试。
• 六个前端相关包的 production build 通过。
• git diff --check 通过。
• 现有测试只覆盖默认的 difile://usr，没有覆盖本次自定义前缀分支。
• 未进行 Android、iOS、HarmonyOS 真机文件读写验证。