ci: harden publish release recovery

[liujuanjuan1984]

Summary

Workflow

• 为 Publish 的 workflow_dispatch 增加显式输入：release_tag、publish_to_pypi、sync_github_release
• 手工触发时强制检出指定 tag，避免误用当前分支头部代码参与发布或补偿
• 将 workflow_dispatch.publish_to_pypi 默认值设为 false，让手工补偿默认走“只修复 GitHub Release、不重复发布 PyPI”的安全路径
• 将 GitHub Release 阶段改为可重试、可补建 release、只补缺失 wheel/sdist 资产的幂等同步流程
• 为同一 tag 增加 workflow 并发收敛，降低重复补偿相互干扰的风险

Docs

• 在 CONTRIBUTING.md 增补 maintainer 侧恢复说明
• 明确手工 dispatch 默认不重发 PyPI，只有维护者明确需要时才设置 publish_to_pypi=true

Commits

• 1ba8280 ci: harden publish release recovery (#359)
• 3d72556 docs: unwrap release recovery markdown lines
• 3b91a6f ci: default manual release repair away from pypi

Validation

• ./scripts/doctor.sh

Issue

• Closes [ops] 记录发布流水线在 PyPI 成功后创建 GitHub Release 失败的脆弱点 #359

[liujuanjuan1984]

本次针对 PR 代码与 issue 关系的自审结论如下。

1. 代码变动审查

• 当前改动整体合理，范围收敛在发布 workflow 与 maintainer 文档，没有把 #359 扩散成更重的发布状态机改造。
• workflow_dispatch 增加 release_tag 后，手工补偿会检出并重建指定 tag，对比原先默认使用当前分支头部代码的行为更稳健，也更符合发布恢复的最佳实践。
• GitHub Release 同步改为“先查 release、缺失则创建、已有资产跳过、失败有限重试”的实现，能直接覆盖 issue 里最关键的半完成发布场景。
• 当前没有发现阻断性问题，也没有发现与主干现状冲突的实现偏差。

2. 风险与边界

• 当前幂等判断以 release 是否存在、资产文件名是否存在为准，并不校验已存在资产的内容一致性；这对“补缺失 release/asset”的目标已经足够，但如果未来需要处理“同名资产损坏或内容漂移”，还需要额外机制。
• 本次变更主要依赖 doctor.sh、YAML 检查和 shell 语法校验，没有真实跑 GitHub Actions 侧的远端集成演练；这是 workflow 类改动的常见剩余风险，但目前属于可接受范围。
• sync_github_release 输入提供了更细的手工控制，但默认值仍为 true，不会影响主路径；如果后续仓库希望进一步收敛操作面，可以再评估是否保留该开关。

3. PR 标题与描述

• 当前 PR 标题 ci: harden publish release recovery 合理，符合 commit message 风格，也准确对应本次主要改动。
• PR 描述已按 Workflow、Docs、Commits、Validation 分块，且已关联 Closes #359；该关系准确，不建议改成 Related。

结论：当前 PR 没有发现需要阻塞合并的问题，能够较稳健地实现 #359 想解决的发布补偿需求。

[liujuanjuan1984]

补充一条后续自审结论：之前的实现虽然提供了 publish_to_pypi 开关，但 workflow_dispatch 的默认值仍是 true，这会让“PyPI 已成功、只缺 GitHub Release”的手工补偿默认走向不安全路径。若维护者直接按默认值重跑，重复 PyPI 发布失败会在 Release 同步之前中断 workflow。

这个问题现在已经修正：

• workflow_dispatch.publish_to_pypi 默认值改为 false；
• tag push 主路径仍保持完整发布；
• 手工 dispatch 默认走“只修复 GitHub Release”的安全补偿路径，只有明确需要时才手动开启 PyPI 发布。

修正后，我对 PR 的结论仍然是：没有阻断性问题，且与 #359 的目标更一致了。