v0.40.8: ImportRepo API write fence (FU-19, #27)

- Every ImportApiService write transaction takes lock_live_import_repo
  (FOR SHARE on the dispatched git_repo row, keyed by its stored path)
  first; a removed repository is IMPORT_REPO_REMOVED (409) and the
  refused step writes no import_refs or git_tag row.
- edit/save: plan_file_edit computes the blob, trees and commit without
  writing; the objects go through the fenced save_entry, then the
  default ref moves in its own locked transaction (update_ref_in_txn).
  get_root_tree / get_tree_by_hash answer NotFound (404) instead of
  panicking; a failed pre-read re-checks liveness (removed_or: exact
  lock-free lookup, same id) and becomes REMOVED only for a gone or
  re-imported repository.
- Tags: annotated create = lock, INSERT ... RETURNING (insert_tag_in_txn)
  and the ref in one transaction, without the compensating delete by
  name; lightweight create = lock and ref; delete = lock, ref and git_tag
  rows (delete_tag_in_txn) in one transaction, no pre-read. REMOVED wins
  over the 404 target / 400 duplicate pre-checks.
- map_ceres_error maps [code:409] to 409 for the tag routes.
- No write transaction takes a second pool connection while open.
- docs/errors.md, directory-entry-api.md and trunk-push.md register the
  API surfaces and the lock order.
- Tests: import_api_service fu19_ (6), 26 reverse checks. No schema
  change.

Plan: docs/plan/plan-20260923.md (FU-19; DEFER-FU-33 closed,
DEFER-FU-38..41).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Eli Ma <eli@patch.sh>

Author: genedna

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "mega2"
-version = "0.40.7"
+version = "0.40.8"
 edition = "2024"
 # Two [[bin]] targets exist; keep `cargo run -p mega2` unambiguous.
 default-run = "mega2"

Cargo.toml

@@ -144,14 +144,14 @@ report-status 行为 `ng refs/heads/main <文本>`；`git push` 显示为 `! [re
 |---|---|---|---|
 | `StaleRef { ref_name, expected }` | `IMPORT_REPO_STALE_REF` | 409 | ImportRepo 推送的 ref 更新未通过服务端 CAS（ADR-FU-08 第 2 条）：`Create` 时该 ref 已存在，`Update` / `Delete` 时它已不再指向客户端声称的 `old_id`（广告之后有别的推送或 API 写入）。`fetch` 后重推即可 |
 | `PathOccupied { path }` | `IMPORT_REPO_PATH_OCCUPIED` | 409 | ImportRepo 推送的挂载位置已被不属于该仓库的内容占用（ADR-FU-08 第 1 条）：该路径在 Monorepo 根树中是普通目录或文件，且没有该仓库的挂载来源记录（存量挂载按「只含 `.gitkeep` 且仓库已有分支」惰性回填，不在此列）。根树不变；换一个路径导入，或由运维清理占用的内容 |
-| `Removed { path }` | `IMPORT_REPO_REMOVED` | 409 | 推送（或编辑保存）进行期间，该 ImportRepo 已被清理（detach，ADR-FU-09 第 5 条）：本次写不落任何行（对象行、tag、分支 ref、`file_path` 都不写，叶子不会被重新挂载）。再推送一次即以新的 `repo_id` 重新导入。Git 面为 `ng` 行原文；API 面 `POST /api/v1/edit/save` 返回 409 |
+| `Removed { path }` | `IMPORT_REPO_REMOVED` | 409 | 推送或产品 API 写（编辑保存、tag 创建 / 删除）进行期间，该 ImportRepo 已被清理（detach，ADR-FU-09 第 5 条）：被拒绝的那次写不落任何行（对象行、tag、分支 ref、`file_path` 都不写，叶子不会被重新挂载）；编辑保存分两个事务写对象行与默认分支 ref，二者之间遇 detach 时，已提交的对象行留给清扫删除。再推送一次即以新的 `repo_id` 重新导入。Git 面为 `ng` 行原文；API 面 `POST /api/v1/edit/save`、`POST /api/v1/tags` 与 `DELETE /api/v1/tags/{name}` 返回 409 |
 | `PathInvalid { path, reason }` | `IMPORT_REPO_PATH_INVALID` | 400 | 路径不是合法的 ImportRepo 叶子（ADR-FU-08 第 7 条、ADR-FU-10 第 1 条）：协议分派在 TP-08 规范化之后、任何查找或注册之前，对进入 ImportRepo 分支的路径（以 `import_dir` 为组件前缀的绝对路径）拒绝 `import_dir` 本身、非规范形式与含 NUL 的路径（SSH 的相对写法如 `third-party` 照旧走 Monorepo 分支，计划 `DEFER-FU-37`）；清理 API 与运维 CLI 的严格入口（FU-20 / FU-21 起）另拒绝 `\`、`..`、重复斜杠与结尾斜杠（`reason` 说明原因；输入可规范化但不是规范形式时给出应使用的规范形式 `did you mean …`）。不写任何行、ref、对象，根树不变 |
 
 出现场景（ImportRepo 推送，`import_dir` 之下；ADR-FU-08 第 1、4、5 条）：tag 命令逐 ref 独立，失败的 tag 得到以 `IMPORT_REPO_STALE_REF` 开头的 `ng` 行；同一推送内的分支命令作为一批在同一 B3 事务内应用，任一分支 CAS 失败则整批回滚、所有分支 `ng`、无一分支前进，各分支的 `ng` 行都是陈旧那条命令的 `IMPORT_REPO_STALE_REF` 原文（只含删除的分支批同样经写入队列、只写 ref，不经物化预检与挂载归属判定，FU-13 起）（`Create` 遇到已存在的 ref 时为 `IMPORT_REPO_STALE_REF: "<ref>" already exists; fetch and push again`）。挂载位置不属于该仓库时得到 `IMPORT_REPO_PATH_OCCUPIED` 原文——首推遇到普通目录或文件，以及后续推送遇到既无来源记录、又不符合存量规则的叶子（例如叶子下已有嵌套子仓的存量父挂载，见计划 `DEFER-FU-23`）。FU-13 起经写入队列的失败不再带 `attach B3 did not complete successfully: {Debug}` 包装：客户端文本按挂载路径与本次推送的分支命令还原为上述类型化错误；物化预检的拒绝保留其明细，为 `Other error: ImportRepo attach failed: <明细>`（I3 祖先 / 后代 / 目标已物化）；其余未归类的失败只返回 `Other error: ImportRepo attach failed (push_queue id <N>); retry the push`，原因只留在队列行（`push_queue.error_message`，可能含存储内部信息，不外露、不写日志）；未执行完的轮次为 `Other error: ImportRepo attach for push_queue id <N> did not complete; retry the push`，等待被放弃为 `Other error: attach wait abandoned for push_queue id <N>`，重放后 ref 仍未生效为 `Other error: ImportRepo attach replayed push_queue id <N> but the refs did not move; retry the push`（这些回落文本是 `MegaError::Other`，`ng` 行带 `Other error: ` 前缀）（v0.40.1 中经队列的分支批失败仍被 Debug 包装）。
 
 出现场景（FU-18 起的写路径存活栅栏与叶子校验，ADR-FU-08 第 7 条、ADR-FU-09 第 2、5 条）：
 
-- `IMPORT_REPO_REMOVED`：receive-pack 在 `unpack ok` 之后，每个 tag 各自得到 `ng refs/tags/<t> IMPORT_REPO_REMOVED: …`；分支批的每个分支得到同一原文的 `ng` 行，不论是哪一道栅栏拒绝（unpack 批、`file_path` 步骤、B3 attach，或已完成的仅删除轮次被重放）；git 客户端显示 `! [remote rejected] main -> main (IMPORT_REPO_REMOVED: …)`。`POST /api/v1/edit/save` 在对象行写入时遇到栅栏返回 409（`err_message` 为同一原文，零对象行）；更早的预读阶段遇到 detach 仍为既有的 500（`DEFER-FU-33`，FU-19）。写入队列行为 `Failed`，`failure_type` 为 `AttachFailure`，`error_message` 为同一原文。
+- `IMPORT_REPO_REMOVED`：receive-pack 在 `unpack ok` 之后，每个 tag 各自得到 `ng refs/tags/<t> IMPORT_REPO_REMOVED: …`；分支批的每个分支得到同一原文的 `ng` 行，不论是哪一道栅栏拒绝（unpack 批、`file_path` 步骤、B3 attach，或已完成的仅删除轮次被重放）；git 客户端显示 `! [remote rejected] main -> main (IMPORT_REPO_REMOVED: …)`。产品 API：`POST /api/v1/edit/save` 在对象行写入时遇到栅栏返回 409（FU-18 起，零对象行）。FU-19 起，请求已分派给 ImportRepo 的处理器之后该仓库才被 detach 时，`POST /api/v1/edit/save` 的预读（因行已删除而失败时再检存活）与默认分支 ref 写、`POST /api/v1/tags`（annotated tag 的 `git_tag` 行与 ref 同一事务，lightweight tag 的 ref）与 `DELETE /api/v1/tags/{name}`（ref 与 `git_tag` 行同一事务）同样返回 409，body 为 `{"req_result":false,"data":null,"err_message":"IMPORT_REPO_REMOVED: …"}`，本次请求不写 `import_refs` / `git_tag` 行（编辑保存在对象批提交之后、ref 写之前遇 detach 时，已提交的对象行由清扫删除）；detach 在分派之前已提交的请求改由 Monorepo 处理器处理（`edit/save` 为 400 `MONO_PATH_NOT_ALLOWED`，见 [refactoring/directory-entry-api.md](refactoring/directory-entry-api.md) 的错误映射）。写入队列行为 `Failed`，`failure_type` 为 `AttachFailure`，`error_message` 为同一原文。
 - `IMPORT_REPO_PATH_INVALID`：HTTP 的 v0/v1 `info/refs`（两种服务）、`git-receive-pack` 与 `git-upload-pack` POST、v2 的 `ls-refs` / `fetch` 返回 400，body 为 `{"req_result":false,"data":null,"err_message":"IMPORT_REPO_PATH_INVALID: …"}`，git 客户端显示 `The requested URL returned error: 400`；v2 的 `info/refs` GET 不分派，仍为 200；认证与推送权限的 401 / 403 先于它；HTTP 的 `/third-party.git` 仍为既有的 `Repository third-party.git is not supported`。`import_dir` 上的 upload-pack 由 404 `Repository not found.` 变为 400。SSH 在 exec 阶段遇到它时通道关闭、无类型化行；在接收数据阶段服务端写出未加 pkt-line 帧的 `error: Invalid Input: IMPORT_REPO_PATH_INVALID: …` 行，git 客户端只显示 `protocol error: bad line length character: erro`（既有的 SSH 错误写法）；SSH 的 `git-receive-pack '/third-party.git'` 同样被拒（此前会注册一行 `import_dir` 记录）。review 策略下的 `POST /api/v1/repo/clone` 丢弃 report-status，前者不达客户端、后者表现为 500（`DEFER-FU-29`）。
 
 ## 响应安全