fix(release): recover immutable-tag publication with reviewed navigation fixture

[loopx-agent]

The immutable 1.4.1 publication is blocked by a navigation fixture that expects an earlier selection after browser Back. The corrected scenario is already merged and reviewed in #6466; admit that one existing fixture owner through the current fixture-only recovery path.

Packages are still built from the original product tag before the correction is copied. Full merged-commit, regular-file, checksum and separately attested product/workflow/fixture source checks remain in force. No product bytes, tag, deployment policy or validation assertion are relaxed.

Validation: existing release-artifacts smoke; six executed recovery cases (including abbreviated/unmerged/unrelated/symlink rejection and unchanged product/artifact bytes); corrected packaged navigation scenario against the immutable 1.4.1 installation; risk-based premerge 19 selected checks plus3 direct checks, zero failures; diff/public boundary checks. The original failed publication remains recorded. Recovery publication and registry readback follow merge.

Scope: S12 release-artifact recovery in the existing release-readiness procedure. A related refactor was unnecessary: adding one existing fixture owner keeps the current bounded mechanism cohesive.

[loopx-agent]

Reviewer: model_agent; model=gpt-6.1-sol; provider=OpenAI; runtime_reported; reasoning_effort=xhigh

Approval conclusion (author-owned PR; GitHub blocks formal self-approval). Exact head 1de0f1a13318dcdd3e1298a8be4903909d68442c.

动机

维护不可变正式版本并向 PyPI 交付安装包的发布者。发布后的浏览器测试仍要求回退到更早选中的任务，主线虽已修正测试，恢复工作流却不允许提取这个场景。恢复入口可以采用这一个已合入并评审的测试文件，继续验证原标签构建的包。本 PR 只交付恢复工具对现有测试 owner 的支持；PyPI 上传成功和全渠道安装读回仍须在实际发布后确认。原发布记录显示失败正好发生在导航回退的旧期望值，而修正后的同一浏览器操作已经对原版本安装包通过，故没有把测试问题误报成产品已修复。

改动思路

复用现有先构建产品、后提取有限测试文件的工作流和来源证明，无需另一套构建、授权或版本选择机制。当前 PR 限于一个精确文件允许项和对应手册，不改变产品标签、默认输入或测试语义。最强反对意见是扩大测试提取范围可能把主线其他产品变动混进发行物。因此检查了原标签 checkout、构建包、有限提取、浏览器检查、恢复夹具及最终校验的完整顺序，并用包含产品文件改动的同一提交执行提取，确认只有允许的测试路径变化。这里用文字即可说明单一路径，没有未验证的流程图。

具体改动

依据是 docs/product/release-readiness.md 在 3a30359712940bf4df9ea719dd8d34b21d089ed6 的 immutable-tag-browser-recovery 条款：从既有标签构建，之后只采用完整已合入提交里的常规测试文件，并分别记录产品、测试和工作流来源。本项在当前 head 已实现。文档只扩展现有 owner 列表，不用本 PR 改过的描述替代既有不可变产品与失败关闭要求。

关键代码讲解

.github/workflows/release-artifacts.yml 的 allowed 集合新增 examples/personal-workspace-browser/goal-workspace-m2.mjs；其余三个 owner 相对产品标签没有变化。changed 仍由精确路径限定的 Git diff 产生，不会把同一提交中的其他产品文件带入。完整 SHA、当前主线祖先检查、100644 常规文件类型检查均保留。RELEASE-SOURCES.json 仍分别写入原产品 HEAD、测试提交、提取路径和工作流身份，供后续 checksum/来源证明验证；新增路径不改变包构建顺序或 provenance schema。对应手册同步这个 owner，其他顺序、权限和停止条件原样保留。

对主干的风险

没有阻断性发现。最主要风险是错拷产品或软链接，以及把修复测试当成跳过测试。实际执行原工作流 Python 的 base/head 六用例覆盖空输入、已合入修正、缩写 SHA、无关提交、未合入提交和软链接拒绝，同时比较产品与预构建包的原字节。基础版本拒绝本次导航修正，当前 head 接受它；默认和各拒绝分支保持原语义。原1.4.1安装包上的 Chromium 场景验证 Back 恢复刚关闭的任务、Forward 关闭和零写请求，接口数据为隔离合成 fixture，不能拿它证明生产数据排序或保存。

现有 release-artifacts smoke、风险 canary 19项与3项 direct checks、diff/公开边界检查通过；精确变更质量凭据有效。按托管策略没有查询 PR CI。原发布失败记录保留，远端恢复构建、PyPI 上传和实际安装读回仍须随后完成。本 PR 不改变前端/Lark/CLI 产品入口或首屏，因此无需产品 companion 改动；也未把当下主线其他功能带入1.4.1。

我的整体评价

APPROVE，交付的是现有恢复机制对缺失测试 owner 的完整支持。long_horizon 改善来自重复发布不必修改不可变标签，user_experience 保持原安装版导航行为和错误可见性。复用现有先构建产品、后提取有限测试文件的工作流和来源证明，无需另一套构建、授权或版本选择机制。当前 PR 限于一个精确文件允许项和对应手册，不改变产品标签、默认输入或测试语义。相关重构检查没有发现值得增加抽象的共同边界。它保留现有本地精确集合，未增加共享状态词表、权限模型、协议版本或自动激活。必须在同一 head readiness 返回 ready 和维护者既有授权下合并，再完成实际发布读回。

English verdict: APPROVE at 1de0f1a13318dcdd3e1298a8be4903909d68442c. One existing reviewed fixture owner enables immutable-tag recovery while preserving product build bytes, exact merged regular-file checks, default behavior and separately attested provenance. Executed base/head recovery counterexamples, installed1.4.1 Back/Forward navigation, artifact smoke and19risk+3direct checks pass. Remote recovery publication and PyPI readback remain pending.

[loopx-agent]

Post-merge correction: the extractor change is valid, but my review missed that the later restoration command repeated only the original three fixture paths. That would leave the new scenario corrected in the runner before attestation, contrary to the documented restoration step. Package bytes are built earlier and remain unchanged. A follow-up replaces the duplicated list with restoration of the existing tracked browser-fixture directory, with an executed base/head extraction-plus-restoration regression. No recovery dispatch has been launched yet.