fix: 自动安装 Webhook、修正 PR 审查范围与分支匹配语义

三个导致「提交了新 PR 但没有任何反应」的独立问题：

1. 从不创建 Webhook
   服务只被动接收事件，但配置仓库时不会去 Gitea 里建 Webhook，
   结果仓库永远收不到 push / PR 事件，看起来和坏掉一样。
   - 保存仓库时自动创建或更新 Webhook（POST /repos 返回值带 webhook 结果）
   - 新增 GET/POST /api/repos/:id/webhook 查询与修复
   - 仓库列表新增 Webhook 列，未配置可一键「修复 Webhook」
   - 新增 CR_WEBHOOK_URL，留空则推导为「Gitea 主机名 + 本服务端口」

2. 审查范围用了错的分支做基准
   resolveRange 优先取 managed_branch 而不是 job.base_ref，
   于是 PR 被拿去和一个无关分支比较；当两者内容相同就报
   「base and head resolve to the same commit」直接跳过。
   改为优先用该改动实际要合入的分支（PR 的目标分支），
   仅 push 事件回退到 managed_branch。

3. 检查分支的匹配语义反了
   原先要求 PR 的 head（功能分支）出现在 check_branches 里，
   而用户配置的是「要保护的目标分支」（如 prd/test），
   功能分支永远不会被列出，所以 PR 一律被过滤掉。
   新增 pullRequestMatches：PR 的 base 命中检查分支即审查，
   head 命中仍保留支持。这样「审查所有合入 prd/test 的改动」成立。

验证：PR offerpai/offerpai_h5#2 重跑通过，7 条内联评论、
2 条阻断、commit status failure、Issue #3 创建。

README.md

@@ -23,6 +23,8 @@ Push / Pull Request 事件
 - 「从 Gitea 导入」一键列出全局 Token 可见的仓库，点「添加」即建好监控配置
 - 手动新增时只填 Git 地址，自动识别 `所有者/仓库名`，旁边可「测试连接」验证
 - 支持 https / ssh / scp 三种地址写法
+- 保存仓库时**自动在 Gitea 里创建 Webhook**，无需手工配置；仓库列表会显示
+  Webhook 状态，未配置可一键「修复 Webhook」
 
 **分支模型**
 - 一个「管理分支」作为唯一合并目标
@@ -140,6 +142,7 @@ curl -fsS http://localhost:8090/api/health
 | `CR_GITEA_TOKEN` | 发布评论、Issue、提交状态用的 Token |
 | `CR_WEBHOOK_SECRET` | Webhook HMAC 密钥；设置后拒绝签名不符的请求 |
 | `CR_ADMIN_TOKEN` | 保护后台和 REST API 的 Bearer Token；设置后打开后台需先输入；留空则不校验 |
+| `CR_WEBHOOK_URL` | Gitea 回调本服务的地址；留空则自动推导为「Gitea 主机名 + 本服务端口」 |
 | `CR_LLM_URL` / `CR_LLM_TOKEN` / `CR_LLM_MODEL` | LLM 端点与凭据 |
 | `CR_LLM_PROTOCOL` | `openai` 或 `anthropic` |
 | `CR_LLM_AUTH_HEADER` | 自定义认证头名，默认由协议决定（如 `x-api-key`） |
@@ -160,7 +163,7 @@ curl -fsS http://localhost:8090/api/health
 | --- | --- |
 | `repo_url` | 仓库 Git 地址，`owner` / `name` 由此自动解析 |
 | `managed_branch` | 唯一的管理分支，所有审查都相对它做对比，也是唯一允许自动合并的目标 |
-| `check_branches` | 纳入监控的分支列表，逗号分隔；支持任意多个 |
+| `check_branches` | 受保护的目标分支列表，逗号分隔。任何**合并进**这些分支的 PR 都会审查（功能分支不必列出），向这些分支推送也会审查 |
 | `review_scope` | `both` / `pr` / `push` |
 | `block_severity` | 阻断级别阈值，如 `critical,high`；留空则不看级别 |
 | `block_categories` | 额外按类别阻断，如 `security` |
@@ -191,6 +194,8 @@ curl -fsS http://localhost:8090/api/health
 | `POST` | `/api/repos/parse` | 解析 Git 地址，返回 `owner` / `name` |
 | `POST` | `/api/repos/branches` | 用 Git 地址查询分支（仓库尚未保存时使用） |
 | `POST` | `/api/repos/:id/branches` | 创建分支，可从指定分支克隆 |
+| `GET` | `/api/repos/:id/webhook` | 查询该仓库的 Webhook 是否已安装 |
+| `POST` | `/api/repos/:id/webhook` | 安装或修复该仓库的 Webhook |
 | `GET` | `/api/records` | 审查历史（`?repo_id=`、`?limit=`） |
 | `GET` | `/api/records/:id` | 单条记录，含参数、意见与摘要 |
 | `POST` | `/api/records/:id/summarise` | 重新排队生成摘要 |
@@ -212,7 +217,7 @@ curl -X POST http://localhost:8090/api/review \
 
 ## 行为说明
 
-**分支与合并**：`check_branches` 里的每个分支都会被监控审查，审查基准是 `managed_branch`（用 merge-base 计算），也就是「这些改动合入管理分支会怎样」。自动合并只作用于目标为 `managed_branch` 的 PR，其他分支的 PR 只审不合。
+**分支与合并**：`check_branches` 是**被保护的目标分支**。任何合并进这些分支的 PR 都会被审查，所以功能分支不必列进去；向这些分支直接推送也会审查。审查基准是该改动实际要合入的分支（PR 用 PR 自己的目标分支，push 用管理分支），也就是「这次改动合进去会怎样」。自动合并只作用于目标为 `managed_branch` 的 PR。
 
 **审查范围**：PR 事件优先用 PR 的目标分支作为基准；push 事件优先用 webhook 里的 `before`，当 `before` 是新建分支的全零值或缺失时，退回到与管理分支的 merge-base。
 
@@ -238,6 +243,9 @@ docker compose build               # 构建镜像
 
 ## 故障排查
 
+**PR 提交了却没有触发审查**
+先看仓库列表的 Webhook 列：显示「未配置」说明 Gitea 不会发事件，点「修复 Webhook」即可。其次确认 `check_branches` 是否包含该 PR 的**目标分支**（不是功能分支）。
+
 **Webhook 投递失败，提示 `webhook can only call allowed HTTP servers`**
 Gitea 拦截了内网地址。按上文给 `[webhook] ALLOWED_HOST_LIST` 加上本服务地址，重启 Gitea。