docs(website): revert the §6.0a "correction" — android-app really had no edge

Phase -1 is now executed, and running it disproved the correction made in the
previous commit. android-app's `edge` did not exist: the push reported
`[new branch]`, and `git ls-remote --heads origin edge` confirms it. §6.0a was
right the first time — three repos needed a branch cut, not two.

The cause is worth keeping, because it read as a real measurement. `git fetch
origin` does not prune, so android-app's `refs/remotes/origin/edge` survived the
server-side deletion after the M12 cutover. rev-parse resolved it and
`rev-list --left-right --count` returned "1 behind" — a plausible number for a
stale branch, which is exactly what it looked like. A remote-tracking ref is a
cache, not an answer; ls-remote is.

Records Phase -1 as complete: five fast-forwards (module-uo 9, installer 7,
servuo-plugins 7, website 5, link 3) plus three branches cut from main
(android-app, runicgateway.com, Integration-kit).

Assisted-By: Claude Code (Opus 5)
Co-Authored-By: Claude <noreply@anthropic.com>

website/ENGAGEMENT.md

@@ -1168,14 +1168,22 @@ different days. `main` must never hold a half-applied set of them.
    refreshed after merging. **Fast-forward each `edge` to `main` before the first phase PR** — it is
    lossless (0 ahead), and skipping it means the cutover diff carries stale content or conflicts that
    have nothing to do with this workstream.
-2. **Two repos have no `edge` at all** and need one cut from `main`: `runicgateway.com` and
+2. **Three repos have no `edge` at all** and need one cut from `main`: `android-app` (its M12 branch
-   `Integration-kit`. *(Corrected 2026-08-28: `android-app` **does** have an `edge`, 1 behind `main`, so
+   was deleted after that cutover), `runicgateway.com`, and `Integration-kit`.
-   it is a fast-forward like the rest. The claim that its M12 branch was deleted after that cutover was
-   wrong.)*
 
-**Phase -1 as actually measured, 2026-08-28.** Six fast-forwards — `module-uo` 9 behind, `installer` 7,
+**Phase -1, executed 2026-08-28.** Five fast-forwards — `module-uo` 9 behind, `installer` 7,
-`servuo-plugins` 7, `website` 5, `link` 3, `android-app` 1 — and two branch creations. `docs`' `edge` is
+`servuo-plugins` 7, `website` 5, `link` 3 — plus three branches cut from `main` (`android-app`,
-already done and is 3 ahead of `main`. Every one is 0 ahead, so all eight are lossless.
+`runicgateway.com`, `Integration-kit`). `docs`' `edge` was fast-forwarded earlier and is ahead. Every
+fast-forward was 0 ahead, so all were lossless. **Phase -1 is complete.**
+
+**One trap worth recording, because it produced a wrong answer here first.** `git fetch origin` does
+**not** prune, so a `refs/remotes/origin/edge` left over from a branch that was deleted server-side after
+a previous cutover still resolves. `git rev-parse --verify origin/edge` succeeds and
+`git rev-list --left-right --count origin/main...origin/edge` returns a plausible count — for
+`android-app` it reported "1 behind", which read exactly like a stale-but-present branch and is why this
+section was briefly "corrected" to say two repos rather than three. The branch had not existed on the
+server since the M12 cutover. **Use `git ls-remote --heads origin edge` (or fetch with `--prune`) to ask
+whether a remote branch exists**; a remote-tracking ref is a cache, not an answer.
 
 **Android CI does not run on `edge`.** `android-app/.gitea/workflows/pr-checks.yml` triggers only on
 PRs into `main`, so every Phase 8 PR lands with **zero CI** and the cutover is the first real run. That