docs(plan): record FIX-MTR-17 attach progress and the ER-03 upload boundary

Signed-off-by: Eli Ma <eli@patch.sh>

Author: genedna

docs/plan/plan-20261015.md

@@ -4546,7 +4546,11 @@ AC1..4是发布前四前置source资格；AC5..8在合法bump之后、C③三门
 
 **Task type:** `implementation`
 
-**Lifecycle / Acceptance:** `pending` / 空
+**Lifecycle / Acceptance:** `in-progress` / 空（attach 侧已按配置算法落地，upload-pack 侧仍有共享管道缺陷，未验收）
+
+**2026-10-31 实施与实测（零 gate claim）：** 已把 ImportRepo 侧七处生产 TLS 转换全部改为显式 kind：新增 `commit_from_git_model_with_kind` / `tree_from_git_model_with_kind`；`incremental_pack` 的 want 提交、父提交走查与 want 树表，have 树走查与 `get_trees_by_hashes`，`collect_git_blob_filepaths`（新增 `kind` 参数并透传递归与两处调用点），`collect_code_tree_objects`（三处），attach 侧 tip 提交与 root 树，均改为按 `object_hash_kind()` 解析。实测又逐层暴露并修掉四处 attach 侧 TLS：`import_leaf_in_txn` / `import_leaf_chain_in_txn` 取显式 kind、`b3_execute_attach` 用 `from_tree_id_with_kind` + `from_hex_for_kind`、`tree_ops::search_and_create_tree` 由根树取 kind 并以 `from_tree_items_with_kind` 建各级树、其 `.gitkeep` 改用 `generate_git_keep_with_timestamp_for_kind`；同时把原先只留在 `push_queue.error_message` 的拒绝原因写进 warn 日志（此前每次 attach 失败都不可诊断）。新增 `tests/integration_import_hash.rs`（真实 Docker Git，ImportRepo 路径）：SHA-256 RED target 与 SHA-1/SHA-256 矩阵覆盖首次 push、快进更新与 have fetch，并按服务端 "retry the push" 约定单次重试（attach 可超出 reaper 的 2 秒 `started_at` 宽限）。
+**实测结果：** `cargo check --all-targets` 干净、`import_hash_` 3/3、`ceres::pack::` 190/190、`import_repo` 41/41；**SHA-1 ImportRepo 矩阵全绿**（首推、更新、have fetch、内容与历史计数）；**SHA-256 首次 push 现已落地**（此前完全不可能），随后 clone 侧失败 `fatal: early EOF / unpack-objects failed`。
+**ER-03 边界（须独立卡）：** 该 upload-pack 剩余失败的调用位点位于本卡 write set 之外——`src/jupiter/storage/mod.rs:1141` 与 `src/server/http_server.rs:435` 仍以 `Tree::from_mega_model` 取根树，且 `git-internal 0.10.2` 的 `internal/pack/encode/parallel.rs:109` 在 SHA-256 下 panic（`converter.rs:993`/`:54` 与 parallel.rs 三处 panic 同现）。本卡不擅自扩大写集，按 ER-03 另行登记前置/后继卡后再修；在补齐前本卡 RED/A/ER05/C/D 均零 claim，版本未 bump、未推送。
 
 **2026-10-31 开工前锚点刷新（未实施，零 claim）：** 前驱 `FIX-MTR-22` 已 `done`/`complete` 并发布 `v0.42.86`（`64e0ed5`，main `41272175017` 与 tag `41272198778` 均 success）。本卡 TLS 依赖面已实测定位：`src/ceres/pack/import_repo.rs` 生产路径仍有七处 `Commit::from_git_model` / `Tree::from_git_model`（约 257、267、291、311、375、522、781 行），其中五处在 `impl RepoHandler for ImportRepo` 内、可直接用已有 `self.object_hash_kind()?`（该 trait 方法已存在），`collect_git_blob_filepaths`（约 514 行起，自由函数，接收 `GitDbStorage`）需新增 `kind: HashKind` 参数并向两处调用点（约 529 递归、925、2016）透传，`collect_code_tree_objects` 一处同需 kind。计划中的"实际使用的 fallible FromGitModel helper"落在 `src/jupiter/utils/converter.rs`，可仿已有 `commit_from_mega_model_with_kind` / `tree_from_mega_model_with_kind` 增补 `commit_from_git_model_with_kind` / `tree_from_git_model_with_kind`，git-db 侧 model 为 `git_commit::Model` / `git_tree::Model`。一次机械替换尝试导致闭包内 `?`、参数个数与未绑定 `kind` 等编译错误，已整文件回退、工作区恢复 0 编译错误；本卡仍未实施，RED/A/ER05/C/D 零 claim，版本未 bump。
 

tests/integration_import_hash.rs

@@ -297,11 +297,12 @@ impl Fixture {
         let output = git_cli::git_cli_no_auth(self.shared.path(), args);
         assert!(
             output.status.success(),
-            "Docker Git {:?} failed: status={} stdout={} stderr={}",
+            "Docker Git {:?} failed: status={} stdout={} stderr={} log={}",
             args,
             output.status,
             String::from_utf8_lossy(&output.stdout),
-            String::from_utf8_lossy(&output.stderr)
+            String::from_utf8_lossy(&output.stderr),
+            self.tail_server_log()
         );
         output
     }