Implement authorization import and revocation checks (T-503)

docs/04-architecture.md

@@ -127,7 +127,7 @@ soft_quay/
 ├─ app/         # 盒子自身程序
 ├─ apps/<id>/   # current/ staging/ backup/ installed-app.json
 ├─ data/<id>/   # 子软件用户数据(更新永不覆盖)
-├─ licenses/    # 许可证(更新永不覆盖)
+├─ licenses/    # 许可证(更新永不覆盖):v1/<sha256>.license 与 revocations-v1.json
 ├─ cache/       # 清单缓存
 │  └─ icons/    # 正式装配的目标图标缓存根;当前以 NewIconCache(root, ...) 实参为事实
 ├─ downloads/   # 下载临时文件 + 任务元数据
@@ -145,7 +145,7 @@ soft_quay/
 
 T-202 将本地识别拆为两层:
 
-- `core/storage`:严格读写 `installed-app.json` v1,读取主文件或中断遗留 backup,并只读检测安装 transaction/journal 是否存在;`files[].path` 与 ZIP/Catalog 共用 Windows 安全相对路径规则。T-401 新记录同时保存已验证的 `entrypoint`、`working_directory`、`min_os` 与 `requires_admin`；旧 v1 记录仍可读取，但缺少完整元数据不能启动。
+- `core/storage`:严格读写 `installed-app.json` v1,读取主文件或中断遗留 backup,并只读检测安装 transaction/journal 是否存在;`files[].path` 与 ZIP/Catalog 共用 Windows 安全相对路径规则。T-401/T-503 新记录同时保存已验证的 `entrypoint`、`working_directory`、`min_os`、`product_id`、`supports_trial` 与 `requires_admin`；旧 v1 记录仍可读取，但缺少启动或 product 授权元数据不能启动。`core/storage.LicenseStore` 只在验签/机器绑定后原子保存 1 MiB 以下的 license document，并在每次读取重新验证；它同样原子缓存已验签的撤销列表，未知/链接/损坏布局 fail closed。
 - `core/domain`:纯 SemVer 2.0.0 比较与 `ResolveAppStatus`,按“恢复事务 → 活跃操作 → 运行 → 不兼容 → 是否安装 → 是否有更新”推导单一状态。
 
 磁盘扫描结果必须在进入 Gio Layout 前准备好;UI 不直接读取 installed-app.json。完整字段见 [api.md](api.md),Schema 为 `schemas/installed-app.schema.json`。
@@ -190,7 +190,7 @@ T-613 已把该状态机的代码层耐久顺序收敛为:payload 的 CRC/长度
 
 T-403 的盒子自更新由独立、无 Gio 的 `SoftBoxUpdater.exe` 完成。它仅接受正 PID、绝对 `<root>/app` 和绝对 `<root>/staging/<request-id>`；request ID 不走 CLI，而是从已准备 staging 的规范目录名派生并复验。旧 PID 自然退出后才检查/恢复上次 journal，随后以 `prepared → target_backed_up → staging_activated → launched → committed` 把 `app` 与同 root staging 受限 rename。T-617 固定 `prepared` 的恢复依据为经 `Lstat` 验证的实际 target/backup 拓扑：仅 target 存在且 backup 不存在才删除 journal；target 缺失且 managed backup 存在必须先 restore；其余组合保留 journal/材料并 fail closed。因此首次 `app → backup` rename 已完成但目录 sync 失败时，当前调用会立即尝试该受限收敛，下一次 Recover 也不会再盲删 journal。`core/updater` 只依赖 PID waiter、固定 launcher、health waiter 和目录同步接口；Windows 的 `OpenProcess(SYNCHRONIZE)`/短等待、无 shell 固定 health 启动和 `FlushFileBuffers` 均保留在两端 `platform/windows`，非 Windows stub fail closed。新版仅能从自身 `<root>/app/SoftBox.exe` 在匹配的已激活 transaction 下写最小 `<root>/self-update-health.json` 确认；确认前旧 backup 不删除，失败优先 restore，文件锁导致 restore 失败则保留 journal/backup 而不强杀。它不提供下载、签名校验、版本选择或 UI 触发，可信 package→staging 链继续后置。
 
-授权:平台层短暂读取严格规范化的 `MachineGuid` 与 Windows 目录所在卷序列号两个必需来源 → 用固定域分隔 SHA-256 生成 `machine_hash` v1（不保存原始 GUID、序列号或 MAC；任一来源失败即拒绝）→ 服务端 Ed25519 私钥对删除顶层 `signature` 后的受限 canonical License v1 JSON 签名 → 客户端 core 以调用方注入的 32 字节公钥离线验签、严格验证九字段并精确比对 machine_hash/product ID;许可证与程序文件、用户配置分开保存;子软件必须独立再次验证,不能只信盒子。受限 canonical JSON 为 Catalog/License 共用的 `core/internal` 实现；core 不读许可证文件也不含生产 key，Windows 采集留在双端 `platform/windows`，非 Windows stub fail closed。导入/存储/试用/撤销/rebind/UI composition 仍属于 T-503。
+授权:平台层短暂读取严格规范化的 `MachineGuid` 与 Windows 目录所在卷序列号两个必需来源 → 用固定域分隔 SHA-256 生成 `machine_hash` v1（不保存原始 GUID、序列号或 MAC；任一来源失败即拒绝）→ 服务端 Ed25519 私钥对删除顶层 `signature` 后的受限 canonical License v1 JSON 与 Revocation List v1 JSON 签名 → 客户端 core 以调用方显式注入的 32 字节授权公钥离线验签、严格比对 machine_hash/product ID，并在 `licenses/v1/` 重新验证缓存；撤销为 current、最多 7 天 grace 或 unavailable/revoked，unavailable/revoked 一律不可授权。安装记录从已验证 `app.json` 携带 product/trial 元数据，启动按 product ID 检查而非 app ID。`core/application.AuthorizationService` 只向 Gio relay 发布净化状态快照，Gio 点击仅入队导入请求，后台 source/read/verify/store 后才发布结果。受限 canonical JSON 为 Catalog/License/Revocation 共用的 `core/internal` 实现；core 不含生产 key，Windows 采集留在双端 `platform/windows`，非 Windows stub fail closed。当前 cmd 明确注入未配置授权 loader；真实 trust root、撤销获取和文件选择 composition 留给发布配置。试用/到期/自助换绑/申诉仍不在客户端实现，子软件必须独立再次验证，不能只信盒子。
 
 ## 六、关键技术难点