ci: run PR checks on pull requests into edge as well as main

Long workstreams land phase by phase on `edge` and reach `main` as a single
cutover. With `branches: [main]` alone, every one of those phase PRs merges
with no checks at all -- no server tests, no client build, no bot install --
and the whole workstream runs blind until the cutover, where the breakage
arrives all at once and un-bisected.

This is not hypothetical: it is what happened to all nine Android M12 phase
PRs in the Android-app repo, whose pr-checks.yml carries the same trigger.

It matters for the module system specifically because Phase 2's exit
criterion IS a CI result -- a zero-line routes.manifest.json diff and a
passing suite -- and that manifest is the frozen URL surface protecting
three shipped clients. A branch accumulating work for weeks needs the gate
more than main does, not less.

Landing before the module-system edge branch is cut, so the first phase PR
is checked. build-images.yml is deliberately untouched: it triggers on push
to main, so images publish and production rolls at the cutover and never
before.

Co-Authored-By: Claude <noreply@anthropic.com>

.gitea/workflows/pr-checks.yml

@@ -1,8 +1,15 @@
-# Gate every pull request into `main` on a fast, DB-free check suite so a broken
-# build or failing test can't reach the deployable branch. Complements
+# Gate every pull request into `main` or `edge` on a fast, DB-free check suite so
+# a broken build or failing test can't reach either integration branch. Complements
 # build-images.yml, which runs only AFTER merge (on push to main) to publish
 # images — this one runs BEFORE merge.
 #
+# `edge` is listed as well as `main` because long workstreams land phase by phase
+# on `edge` and reach `main` as a single cutover (the module system, protocol v3).
+# With `branches: [main]` alone, every one of those phase PRs merges with NO checks
+# at all and the entire workstream runs blind until the cutover — which is exactly
+# what happened to the nine Android M12 phase PRs in that repo. A branch that
+# accumulates work for weeks needs the gate more than `main` does, not less.
+#
 # Enforcement (one-time, in the Gitea UI):
 #   Repository Settings → Branches → Branch Protection (rule for `main`)
 #     • Enable Status Check
@@ -10,6 +17,10 @@
 #   Note: Gitea only lists a context in its dropdown after it has reported once,
 #   so let this workflow run on one PR first. The `PR Checks / *` glob matches
 #   without needing the dropdown.
+#   The workflow now RUNS on PRs into `edge` too, but running is not enforcing:
+#   blocking a red phase PR needs its own protection rule for `edge`, with the
+#   same `PR Checks / *` pattern. Without one the checks report and merging stays
+#   possible anyway.
 #
 # Runner: reuses the existing self-hosted `ubuntu-latest` runner. These jobs need
 # only Node (no Docker socket), and the server tests stub their models + point the
@@ -19,7 +30,7 @@ name: PR Checks
 
 on:
   pull_request:
-    branches: [main]
+    branches: [main, edge]
 
 # A newer push to the same PR cancels the in-flight run.
 concurrency: