build(release): stage local macOS v0.1.0 distribution

docs/guides/branch-maintenance-sop-zh.md

@@ -108,6 +108,8 @@ npm run desktop:build:app
 
 正式桌面发布构建必须从同一正式 tag 分别在 macOS 和 Windows 原生 CI job 执行。两端都必须设置 updater 签名私钥，updater 签名不可关闭。平台签名默认路径仍要求 macOS 设置 Apple 签名/公证变量并以 `REQUIRE_DESKTOP_SIGNING=true` 执行，Windows 设置 PFX、密码和 RFC 3161 时间戳变量并以 `REQUIRE_WINDOWS_SIGNING=true` 执行。只有 `frontend/desktop-release-policy.json` 对当前精确版本存在已批准例外时，workflow 才可改为 macOS ad-hoc、Windows Authenticode 未签名路径；例外制品必须标注 `UNSIGNED-PLATFORM`、生成 provenance 和风险说明。两个平台与联合 feed 校验通过后才能汇总正式 updater feed。
 
+v0.1.0 额外批准 GitHub Actions 额度不可用时的分阶段应急路径：先在受控 macOS 主机从最终、不可移动的 `v0.1.0` tag/SHA 本地构建并上传 macOS ad-hoc 制品，随附 updater `.sig`、checksum、provenance、平台未签名警告和 Windows pending 说明；Windows 恢复后必须从同一 tag/SHA 后补。macOS 先行阶段不得发布或替换生产 `latest.json`，联合 feed 必须等待 Windows `NotSigned` 实物验证完成。
+
 后端改动应补充执行受影响模块的后端测试、迁移检查和接口回归。
 
 ### 4. 创建提交
@@ -297,6 +299,8 @@ git push origin v1.2.0
 
 网页端、macOS 和 Windows 桌面端必须从同一个 `v1.2.0` 标签构建。不得从不同分支、不同提交或本地未提交状态构建正式制品。两个平台的 updater 签名制品必须始终验证通过；macOS 签名/公证和 Windows 代码签名/RFC 3161 时间戳必须验证通过，除非 `frontend/desktop-release-policy.json` 对该精确版本记录了已批准例外。采用例外时必须验证 macOS 确为 ad-hoc、Windows 确为 `NotSigned`，并随安装包分发 `UNSIGNED-PLATFORM` 风险说明、provenance 和 checksum，之后才能最后原子替换生产 `latest.json`。
 
+若执行 v0.1.0 的已批准分阶段应急路径，首次 macOS Release 可先于 Windows 发布，但 tag/SHA 不得移动；首次 Release 不包含 `latest.json`，并必须明确标记 Windows pending。Windows 后补且联合 feed 验证通过后，才允许按上述顺序激活生产 updater feed。
+
 发布记录至少包含：
 
 - 产品版本号