release: 发布 v0.6.4 环境自适应与 macOS 打包

新增能力：桌面端新增 macOS 打包支持，electron-builder 增加独立 mac 配置块，
产出 dmg，按 arm64、x64 分别单独构建、不产出 universal 包；Pandoc 运行时清单
新增 darwin/arm64、darwin/x64 两个官方发行项（含独立许可证文件来源），桌面
Pandoc 候选路径与 prepare-pandoc-runtime.mjs 均已泛化为按 --platform/--arch
参数选取目标，不再只认 Windows x64。AGENTS.md 不再硬编码 Windows 绝对路径与
强制 PowerShell 语法，改为按当前 Shell 与仓库实际位置自适应。

问题修复：修复解压内置 Pandoc 时未保留 Unix 可执行权限位的问题（unzipSync
不保留压缩包内权限，已补 chmod 0o755）；修复根 package.json 中
build:web-runtime/dev/desktop:dev 三个脚本的构建顺序错误
（@md-to-pdf/application 被排在其依赖的 @md-to-pdf/preview-engine 之前，在
没有历史 dist 残留的全新环境中会导致类型解析失败）；修正
packages/docx-engine/tests/pandoc-runtime.test.ts 与
apps/desktop/tests/markdown-file.test.ts 中依赖宿主 OS 或路径分隔符的测试
断言，避免这些用例只能在特定平台上通过。

验证结果：docx-engine 包 93 项测试、desktop 包 62 项测试（61 通过 + 1 项
Windows 专属用例按预期跳过）均通过；全项目类型检查、生产构建通过，
git diff --check 无空白错误。跳过依赖 Git 忽略的真实客户文档语料（tmp/）的
test:docx-real-world-corpus 与 test:docx-release-gate-suites 后，其余全部
工作区测试均通过；这两步需要接入真实语料的机器上单独执行。本机 macOS
（Apple Silicon）实测 npm run package:mac:arm64 全链路成功，内置 Pandoc
3.9.0.2 完成下载、哈希校验与真实 DOCX 冒烟转换；实际截图确认窗口、macOS
原生菜单栏、编辑器工具栏、中文字体与实时预览渲染正常。

兼容与部署：版本统一为 0.6.4。本版本仅完成开发基础设施与验证，未构建正式
发行文件：没有产出真实签名的 dmg、没有重新构建 Windows 安装包，也没有重新
构建 Docker 镜像；正式 macOS 发行产物与 Windows/Docker 同步验证留待 DOCX
发布门禁阶段完成后一并发布。

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K5N6pcbjV4jVfXrcH3NcLP

deploy/README.md

@@ -38,7 +38,7 @@ docker compose -f deploy\compose.yaml down
 可以直接指定版本化镜像名称构建：
 
 ```powershell
-$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.2'
+$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
 docker compose -f deploy\compose.yaml build
 ```
 
@@ -48,13 +48,13 @@ docker compose -f deploy\compose.yaml build
 已经保留同版本系列的已验证镜像，可在内网或软件源较慢时复用其运行层：
 
 ```powershell
-$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.2'
+$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
 $env:MD_TO_PDF_RUNTIME_BASE_IMAGE = 'yixiong/md-to-pdf:v0.6.0'
 $env:MD_TO_PDF_REUSE_PLAYWRIGHT_RUNTIME = '1'
 docker compose -f deploy\compose.yaml build
 ```
 
-复用模式会校验基础镜像中存在 Chromium，再覆盖 v0.6.2 应用代码和生产
+复用模式会校验基础镜像中存在 Chromium，再覆盖 v0.6.4 应用代码和生产
 依赖。正式跨机器构建仍建议使用默认完整路径。
 
 ## 主题挂载
@@ -76,7 +76,7 @@ docker compose -f deploy\compose.yaml up -d
 
 ## 内置字体包
 
-v0.6.2 的发行镜像固定将受校验字体包内置到
+v0.6.4 的发行镜像固定将受校验字体包内置到
 `/app/.local/font-packs`。Compose 不挂载宿主机字体目录，因此部署端
 无需额外复制字体，Preview、PDF 和 DOCX 可以离线使用同一套原生资产。
 
@@ -104,7 +104,7 @@ docker compose -f deploy\compose.yaml up -d
 发布前执行真实内置字体门禁：
 
 ```powershell
-$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.2'
+$env:MD_TO_PDF_IMAGE = 'yixiong/md-to-pdf:v0.6.4'
 npm run verify:docker-font-pack
 ```
 
@@ -122,7 +122,7 @@ npm run verify:docker-font-pack
 | `MD_TO_PDF_REUSE_PLAYWRIGHT_RUNTIME` | `0` | 是否复用基础镜像中的 Chromium |
 | `MD_TO_PDF_PORT` | `8080` | 宿主机监听端口 |
 | `MD_TO_PDF_THEME_DIR` | `../.local/themes` | 宿主机主题目录 |
-| `MD_TO_PDF_APP_VERSION` | `0.6.2` | 字体包兼容性判断使用的应用版本 |
+| `MD_TO_PDF_APP_VERSION` | `0.6.4` | 字体包兼容性判断使用的应用版本 |
 | `PDF_CONCURRENCY` | `1` | 同时执行的 PDF 任务数 |
 | `PDF_MAX_QUEUE` | `4` | 等待队列上限 |
 | `PDF_TIMEOUT_MS` | `120000` | 单次 PDF 生成超时 |

deploy/compose.yaml

@@ -19,7 +19,7 @@ services:
       PDF_CONCURRENCY: "${PDF_CONCURRENCY:-1}"
       PDF_MAX_QUEUE: "${PDF_MAX_QUEUE:-4}"
       PDF_TIMEOUT_MS: "${PDF_TIMEOUT_MS:-120000}"
-      APP_VERSION: "${MD_TO_PDF_APP_VERSION:-0.6.2}"
+      APP_VERSION: "${MD_TO_PDF_APP_VERSION:-0.6.4}"
       FONT_PACK_ROOT: /app/.local/font-packs
     volumes:
       - "${MD_TO_PDF_THEME_DIR:-../.local/themes}:/app/.local/themes:ro"

deploy/verify-font-pack-compose.mjs

@@ -175,7 +175,7 @@ const environment = {
   ...buildEnvironment,
   MD_TO_PDF_PORT: String(port),
   MD_TO_PDF_THEME_DIR: themeRoot,
-  MD_TO_PDF_APP_VERSION: "0.6.2"
+  MD_TO_PDF_APP_VERSION: "0.6.4"
 };
 const compose = [
   "compose",