[REQ-128][CODE] re-vendor alpha-web producer 产物,追平 #102 之后的 pin #738

大白话:这是什么

alpha-code 里存了一份 alpha-web 已发布产物的副本(vendored),用来在没网的情况下
对着契约做校验。这份副本是按内容摘要钉死的 —— 对面仓一发新版本,这边就落后一版。

今天它已经落后一版了,而 REQ-128 收尾的两张票会让它再落后一版。本票是把它追上来。

今天的事实(实跑)

• packages/alpha-contracts-consumer/alpha-web-extension-package.lock.json:3 钉的是
  alpha-web b71748103ce65f97e3e5c8ac03f08152a0a1456f;
• alpha-web 的 origin/main 已经是 3847db1(alpha-web#101 合并所致),落后一个提交;
• alpha-web#102 合并后还会再产生一版(组件 id 上界 + 生成器 schema 同步);
• alpha-code#729 会改宿主聚合 SHA,alpha-web#102 随之升 pin —— 于是 vendored 的
  host-contract-pin.v1.json 也会变。

为什么现在不做(这一条是本票存在的理由)

alpha-code#729 的实现方被明确禁止顺手同步 vendor,因为那会同时打红两条闸:

• packages/alpha-contracts-consumer/src/extension-package-artifact.test.ts:46
  断言 lock.files.length === 22;
• :50 逐文件比 sha256;:51-55 / :79 再比 producer manifest 的 bytes+sha 与聚合。

让 vendor 停在旧字节是诚实的 —— 它记录的就是 alpha-web 今天钉的那一版。
但这个"诚实的落后"需要一张票拥有它,否则就是一个没人负责的漂移。

Development plan

1. 等 alpha-web#102 合并(它同时携带 alpha-code#729 之后的宿主 pin bump)。
2. 跑 vendor 脚本重新拉取。
3. 同步三处硬编码(这三处不会被脚本自动覆盖):
   • packages/alpha-contracts-consumer/alpha-web-extension-package.lock.json:3 的 commit
   • packages/alpha-contracts-consumer/scripts/vendor-alpha-contracts.ts:94 的 commit 字面量
   • packages/alpha-contracts-consumer/src/extension-package-artifact.test.ts:41-46 里写死的
     commit: "b71748103…" 与 artifactSha256: "ae9f43cc…"
4. 若 alpha-web#102 往 vectors.v1.json 增减了负向向量,
   extension-package-artifact.test.ts:140-154 的 toEqual 精确映射与 :28 的
   「all 22 exact files」也要同迭代跟改。

Acceptance

• bun test src 全绿,extension-package-artifact.test.ts 的四条闸(文件数 / 逐文件 sha /
  producer manifest / 聚合)全部对上新版本。
• lock 里的 commit 与 alpha-web 当时的 main 一致 —— 在 PR 里贴出那个 commit,
  不要写"最新"。

Out of scope

• alpha-web 侧任何改动;
• 改变 vendor 机制本身。

Dependencies

alpha-web#102(必须先合)。

备注

这是跨仓 pin 的常规维护,不是缺陷修复。之所以单独开票,是因为
alpha-code#729 / alpha-web#102 的边界都明确把它排除在外 ——
不给它一个 owner,它就会变成一个没人看见的漂移。