[BUG][P1] pre-push 钩子对任何 push 恒假红:git push 注入的 GIT_DIR 压过 vendor 校验的 -C

[jinjunnn]

大白话

这个仓的 pre-push 钩子对任何一次 push 都必然报错，原因与被 push 的内容无关。
后果是所有人都用 --no-verify 绕过它 —— 一道恒红的闸 = 没有闸，而且比没有闸更糟，
因为大家以为它在把关。

真因（实测，不是推断）

链路：.githooks/pre-push → scripts/alpha-check.sh → packages/alpha-contracts-consumer 的 check:vendor。

scripts/vendor-alpha-contracts.ts:172 用 git -C <sourceRoot> rev-parse 校验兄弟仓（alpha-web）的提交。
而 git push 会向钩子进程注入 GIT_DIR，它会压过 -C ⇒ 解析落到 alpha-code 自己的 git dir，
兄弟仓的 commit 当然解析不出来。

实测对照：

$ GIT_DIR=$(git rev-parse --git-dir) bun run check:vendor
error: required producer commit does not resolve exactly:
  jinjunnn/alpha-web@83acf3a513cdda2da9fadddfea1a4ee837e197d2 in /Users/tide/app/alpha-web
  at .../scripts/vendor-alpha-contracts.ts:172:19

$ bun run check:vendor        # 不带 GIT_DIR
exit=0 · 22 个 artifact verified

为什么值得单独修

这条不是"某个 PR 的红"，是结构性恒真：只要经 git push 触发，就必红。
本仓 CLAUDE.md 已经把 pre-push 钩子写成第一道门、CI 只兜底 —— 而这道门今天实际上是关掉的。

Development plan

1. 在 scripts/vendor-alpha-contracts.ts 调 git 子进程时显式清掉 GIT_DIR 与 GIT_WORK_TREE
   （以及任何其它会压过 -C 的 git 环境变量），而不是依赖 -C 生效。
2. 枚举同类：仓内还有哪些脚本用 git -C <别的仓> 且可能在钩子/CI 上下文里跑？
   用两条互相独立的检索轴查（git -C 字面量轴 + 生成子进程的调用点轴，rg -a），一并收口。

Acceptance and named gates

• 一条回归：在设置了 GIT_DIR 的环境里跑 check:vendor，必须与不设时结果一致。
  判据 = 把修复移除后该用例变红。
• 真跑一次不带 --no-verify 的 git push（可 push 到临时分支后删），确认钩子通过。
• 枚举证据：两条检索轴的结果各贴一份。

出处

alpha-code#705 的审计修复过程中发现（该 PR 因此用了 --no-verify 并在 PR 里写明理由）。