Say what the mirror's concurrency group does, and name every way a stale ref survives

.gitea/workflows/mirror-delete.yaml

@@ -7,7 +7,6 @@ permissions:
   contents: read
 
 jobs:
-  # No concurrency group: Gitea cancels a queued run when the next one in its group arrives, dropping the delete.
   delete:
     runs-on: ubuntu-24.04
     timeout-minutes: 10

.gitea/workflows/mirror.yaml

@@ -13,7 +13,7 @@ jobs:
   push:
     runs-on: ubuntu-24.04
     timeout-minutes: 10
-    # Gitea 1.26 rolls back a run whose jobs share a group, so the delete job lives in mirror-delete.yaml.
+    # Gitea cancels a queued job in this group when the next one arrives; only the full push may join.
     concurrency:
       group: mirror
     steps:

AGENTS.md

@@ -148,9 +148,9 @@ docker compose run --rm node npm run build
   TypeScript 7 once that constraint lifts.
 - GitHub mirrors Gitea through `.gitea/workflows/mirror.yaml`, which never prunes, and
   `mirror-delete.yaml`, one run per deleted ref. A delete run that fails or outlives Gitea's queue
-  timeout leaves the ref on GitHub until it is re-run. Accepted: a stale ref there is harmless, and
-  refs only GitHub has must survive. Maintainer's call, 2026-09-14; valid while nothing deploys from
-  GitHub.
+  timeout, or a push run that cloned before the delete, leaves the ref on GitHub until the delete
+  run is re-run. Accepted: a stale ref there is harmless, and refs only GitHub has must survive.
+  Maintainer's call, 2026-09-14; valid while nothing deploys from GitHub.
 
 ## Defects found in 0.4.0