fix: 所有问题都建 Issue、合并失败重试、push 与 PR 事件分流

1. 所有问题都建 Issue（原先只有阻断级才建）
   建 Issue 的判据从 blocking 改为 findings：任何等级的问题都创建/更新 Issue，
   等级体现在标题 [OCR][medium] 与标签 medium 上，阻断项在正文标注
   「（阻断合并）」。低等级问题不再丢失，也不会挡住合并。
   无任何发现时才关闭该分支的 Issue。

2. 合并失败自动重试
   Gitea 在算完 PR 可合并性之前会返回 405 Please try again later，
   原先直接放弃，晋级随机失败。现在对 405/409/5xx 按指数退避重试 4 次；
   权限不足、真实冲突等永久失败立即放弃并往 PR 留言说明。
   PR 已被合并（405 already merged）视为成功，幂等收尾。

3. push 与 PR 事件分流（本次新发现的 bug）
   合并路径原先按「是否找到关联 PR」判断，于是一个残留的 test→prd PR
   会让后续 push 被当成 PR 事件，走错分支并跳过晋级，日志还会给出
   「PR targets prd, which is not a checked branch」这种与实际不符的原因。
   现在按事件类型决定：trigger 以 pull_request 开头才走合并 PR 路径，
   push/manual 一律走晋级分支。关联 PR 仅用于评论归属。

验证：
- 直接 push test → 建出 issue #4（[OCR][medium]，标签 code-review,medium）
- 合并重试与幂等分支的判定表全部通过
- 事件分流判定表：push/manual → promote，pull_request.* → merge PR

README.md

@@ -243,6 +243,18 @@ push 时已经审过，重复审会在代码合并后凭空造出 Issue。
 该仓库所有由本服务创建的 open Issue 都会被评论并关闭——代码已经落地，
 上一轮的问题描述的是不再存在的状态。下一个问题会在下一次审查时重新开 Issue。
 
+**审查发现都会建 Issue**，与是否阻断合并无关。等级体现在 Issue 标题与标签上
+（`[OCR][medium] …`，标签 `medium`），阻断项在正文里额外标注「（阻断合并）」。
+这样低等级问题不会丢失，也不会挡住合并。
+
+**合并路径由事件类型决定**：push 事件永远走「晋级分支」，PR 事件才走「合并该 PR」。
+早先按「是否找到关联 PR」来判断，导致一个残留的 `test → prd` PR 会让后续
+push 误判成 PR 事件、跳过晋级。关联 PR 现在只用于评论归属，不参与路径选择。
+
+**合并失败会自动重试**：Gitea 在算出 PR 可合并性之前会返回 `405 Please try again later`，
+这类暂时性失败（405/409/5xx）按指数退避重试 4 次；权限不足、真实冲突等
+永久性失败立即放弃，并在 PR 上留言说明原因。若 PR 已被合并，视为成功。
+
 **审查范围**：PR 事件优先用 PR 的目标分支作为基准；push 事件优先用 webhook 里的 `before`，当 `before` 是新建分支的全零值或缺失时，退回到与管理分支的 merge-base。
 
 **审查背景**：仓库配置里的「审查背景 / 需求」是多行文本，既作为 OCR 的 `--background` 传给模型，也会完整记录到审查历史，方便回溯「当时是按什么需求审的」。