tools-sync: 增加 ls-remote 同步闸门，并记下 gitea 空 pack 故障的排查法

这次同步事故的教训不是服务器坏了，而是坏了没人知道：pull --rebase 一失败脚本
就退出，push 从没走到，3 个 commit（含整个 bmem skill）在本机躺了 8 天，报告里
却算作"已知故障、待恢复"。而 ls-remote 这 8 天一直是好的。

- sync_repos.ps1 增 Assert-RemoteInSync：push 后（及 -DryRun 时）用 ls-remote 比对
  origin/<branch> 的实际 sha，不一致就 FAIL 并报出滞留/落后的 commit 数。
  远端分支不存在时单独报错，避免那两个计数被静默地按 HEAD 算出误导性数字。
- SKILL.md 阶段 1 写明闸门是硬性的：服务端故障是原因不是结果，不得报成已同步。
- SKILL.md 新增 bad pack header / early EOF 的排查阶梯（三步各排掉一层），并记下
  根因：全局 gitconfig 被注入 [uploadpack] packObjectsHook，把 pack-objects 换成
  了空转脚本。附带提醒 HOME 是 /data/gitea/home 而非 /data/git，以及这是一条
  完整 RCE 链、要连 hook 与 /tmp 载荷一起清。
- bmem/SKILL.md 的"已知边界"改为已修复，避免继续把普通的没 pull 误判成服务端故障。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015tMFjKGgxdmxJ28dyXdx1u

bmem/SKILL.md

@@ -277,6 +277,8 @@ bmem delete --yes --sync # 确认执行并同步给其它机器
 | 注销项目 | `bmem delete`（预览）/ `bmem delete --yes --sync`（执行） |
 | 帮助 | `bmem help` |
 
-已知边界：当前 gitea 的 pack 服务故障，**push 正常但 clone/fetch 失败**，所以第二台机器
-暂时拉不到 Markdown 层（log 层走 PostgreSQL 不受影响，Notes 全文在中心库里）。
-看到 `bmem machines` 报"本机的 bmem.md 落后了"时，先想到这条。
+曾经的边界，**2026-09-02 已修复**：gitea 的 pack 服务坏了约一周（push 正常、clone/fetch
+报 `bad pack header`），Markdown 层因此在机器之间停摆。根因是 gitea 的全局 gitconfig 被注入
+了 `[uploadpack] packObjectsHook`，把 `git pack-objects` 换成了一个不产出 pack 的脚本；
+排查与处置写在 tools-sync skill 的阶段 1。现在 `bmem sync` 的 git 部分应当正常。
+再看到 `bmem machines` 报"本机的 bmem.md 落后了"，就按普通的没 pull 处理，不要再归因于服务端。