merge: require cover for first project submission

.project-docs/40-domain/business-rules.md

@@ -13,7 +13,7 @@
 - 客户端预检是可绕过的 UX fail-fast，不上传可信 receipt，也不声称具备生产 opaque-origin parity。服务端把源码、构建归档和 contract 当作不可信字节，独立重算、校验并固化不可变 Release；人工审核仍是不可绕过发布门禁。未来若要求 runtime 强门禁，必须由可信 verifier 绑定精确构建产物。
 - 发布安全边界由 Electron Main 持有，Renderer 不接触账号 Token、ZIP、幂等键和本地绝对路径。
 - 发布 Host API 必须在读取凭据、查询项目和打包前校验 Renderer capability；仅持有 Host token/base 的非 UI 调用方不得发起发布。
-- 当前 Works Project 契约没有可验证的 metadata revision/ETag、draft-only 条件写或封面删除/原子绑定能力。首次发布只允许在 project create 中原子保存文字资料并暂不上传封面；已有 draft/published 只提交新版本并沿用平台资料与封面。404→create 409 等状态竞态必须固定失败并要求重新确认，不得上传孤立封面、无条件 PATCH 或静默丢弃表单资料。
+- 首次 Works Project 发布必须选择 PNG/JPEG/WebP 封面（不超过 10 MiB），并由 Electron Main 将项目资料与封面通过服务端单一 multipart create 合同原子绑定；Renderer 仅传有界封面 DTO，不接触 Works Token、项目路径、归档或幂等身份。服务端创建冲突或失败时客户端必须停止版本上传，不能回退到先传封面再 JSON create。已有 draft/published 仍只提交新版本并沿用平台资料与封面；在具备 metadata revision/ETag 与 draft-only 条件写前，不得用无条件 PATCH 模拟已有资料编辑。
 - 客户端只持久化服务端已接受的 submission binding v2。旧 `submitted` 绑定必须保留；旧 `armed`、`waiting_for_package`、`waiting_for_login`、`uploading`、`failed` 必须迁移为可理解的 `legacy_retired`，不得恢复后台任务。
 - 云端上传成功但本机 submission binding 保存失败时，提交仍视为成功；客户端显示固定、无本地路径的告警并继续轮询服务端校验与 Release 固化状态，避免诱导重复提交。
 - 旧客户端缺少 source+built+contract 新协议，或服务端仍存在旧 sandbox/browser 任务时，必须提示升级客户端并重新构建提交；不得把它们伪装为新版瞬时故障。新版合同校验后的 `BUILD_STALE`、归档存储或 ReleaseStore 瞬时失败由运营在“构建异常”中重试。