Point the fork's main at upstream too, so a fresh clone is right

The local fix left `origin/main` at the app's line, so a fresh clone of the
fork -- which has no `upstream` remote -- still resolved `main` to the wrong
base. Force-pushed to `ca2b4b2` with `origin/HEAD` following it; the app's
45 commits stay reachable through `app-pin`, which was pushed first.

Verified by cloning the fork: `git merge-base main <branch>` gives ca2b4b2
with only `origin` configured, the parley migration no longer appears in the
diff, and the pinned `32f6ad8` is still present.

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

docs/HANDOFF.md

@@ -71,11 +71,17 @@ Bryan asked for the setup fixed rather than documented. What changed:
 - `git iris-base` and `git iris-diff` are still configured and still
   correct; they now agree with plain `main`.
 
-The submodule's recorded commit is unchanged at `32f6ad8`, so nothing about
-the app's pin moved -- only the name it is reachable by. **`origin/main` on
-the fork is still `32f6ad8`**: moving it is a non-fast-forward on a shared
-branch, so it is left for Bryan to decide. Until it moves, a *fresh clone of
-the fork* still gets the old, misleading `main`.
+`origin/main` on the fork was force-pushed to match, and `origin/HEAD`
+follows it, so a fresh clone of the fork with no `upstream` remote gets the
+right base from the plain commands too -- verified by cloning one. The
+fork is managed entirely by agents and nobody works from it directly, so
+rearranging its branches is always safe where it improves the workflow
+(Bryan, 2026-09-20); that licence does not extend to the `iris/`
+repositories, which are what pull requests target.
+
+The submodule's recorded commit is unchanged at `32f6ad8` and stays
+reachable through `app-pin`, so nothing about the app's pin moved -- only
+the name it is reachable by.
 
 ### How to check a round