feat: 打通 推送→审查→晋级→关闭 Issue 的完整闭环

直接推送也能晋级
  往受保护分支直接推代码（没有 PR）时，审查通过后自动开一个
  <分支> → <管理分支> 的 PR 并合并它，而不是放弃自动合并。
  已存在同类 open PR 时复用它，不重复创建。

晋级 PR 不再被重复审查
  自动创建的 PR 带 PROMOTION_MARKER，其 pull_request 事件直接跳过。
  同一批提交在 push 时已经审过，重复审会在合并完成后凭空造出 Issue
  （此前确实产生了这样一个幽灵 Issue）。

合并即关闭该仓库全部审查 Issue
  两条触发路径：
  - 服务自己完成合并后立即关闭
  - 人在 Gitea 手动合并时，pull_request closed + merged=true 事件触发关闭
  手动合并是「代码已落地」最可靠的信号，不再依赖 push 侧的 merge 提交探测。

晋级使用 merge 而非 squash
  squash 会把晋级提交重写成全新提交，两个长期分支每晋级一次就多分叉
  一点，最终必然冲突（已在 offerpai_h5 上复现 add/add 冲突）。
  merge 保留共同祖先，下次晋级只携带新提交。

合并可等待性
  Gitea 异步计算 mergeable，原先只轮询 5 秒就放弃。改为指数退避约 30 秒，
  并区分「尚未算出」（继续等）与「确实冲突」（放弃）。失败时往 PR 留评论
  说明原因，不再只写服务日志。

验证（真实 webhook）：
  推送 test → 审查通过 → 自动开 PR #9 (test→prd) → merge 合并
  → pull_request merged 事件 → 关闭 0 个待处理 Issue
  prd 顶端前进为合并提交，test/prd 保持一致，无幽灵 Issue 产生

README.md

@@ -227,8 +227,22 @@ feature/xxx ──PR──> test ──PR──> prd
                           ↑ 第二级：同样审查通过才合并
 ```
 
+**直接推送**也走同一条链路：往 `test` 推代码（没有 PR）时，审查通过后服务会
+自动开一个 `test → prd` 的 PR 并合并它，然后关闭该仓库所有审查 Issue。
+
+自动开的晋级 PR 会带一个标记，它自身的 webhook 事件会被忽略——同一批提交在
+push 时已经审过，重复审会在代码合并后凭空造出 Issue。
+
+晋级 PR 始终使用 `merge` 而非 `squash`：squash 会把提交重写成全新提交，
+两个长期共存的分支每晋级一次就多分叉一点，最终必然冲突；真正的 merge
+保留共同祖先，下次晋级只携带新提交。
+
 `managed_branch` 只决定「push 事件没有对应 PR 时，拿哪个分支做对比基准」，以及新仓库的默认值。
 
+**Issue 生命周期**：只要发生合并（服务自动合并、或人在 Gitea 里手动合并），
+该仓库所有由本服务创建的 open Issue 都会被评论并关闭——代码已经落地，
+上一轮的问题描述的是不再存在的状态。下一个问题会在下一次审查时重新开 Issue。
+
 **审查范围**：PR 事件优先用 PR 的目标分支作为基准；push 事件优先用 webhook 里的 `before`，当 `before` 是新建分支的全零值或缺失时，退回到与管理分支的 merge-base。
 
 **审查背景**：仓库配置里的「审查背景 / 需求」是多行文本，既作为 OCR 的 `--background` 传给模型，也会完整记录到审查历史，方便回溯「当时是按什么需求审的」。