docs(link): the cutover, and the counter two branches bumped at once (Phase 9b)

Records the Asset Bridge `edge -> main` cutover: §16's 9b row, §17.15's four
org-lead decisions, and the `PARSER_VERSION` correction those forced through
§7, §10.4 and `SPAWN_ATLAS.md`.

## The number had to move, and the reason generalises

§10.4 wrote phase 7's canonical-read-order bump as `PARSER_VERSION` 4 -> 5.
`main` had meanwhile bumped 4 -> 5 for the `UniqueId` fix and RELEASED it as
v1.2.2. Same number, different derivation. An install that imported under
v1.2.2 stores 5, so a phase-7 build also declaring 5 is read as current by
`currentParser` and never re-reads -- the exact failure the constant exists to
prevent, reached through a merge instead of through forgetting to bump.

Two long-lived branches bumping one counter for different reasons is a defect
the counter cannot see; only the merge can. The docs now carry both meanings --
5 as main's released one, 6 as phase 7's -- rather than collapsing them.

## The cutover is five repos

`installer`'s `edge` carried 9a's `libgdiplus` `doctor` check, and
`SHARD_PREREQS.md` on `main` had been describing that check as existing since
phase 1. §16's 9b row named four repos and would have left an operator-facing
doc naming a check in no released binary.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

website/SPAWN_ATLAS.md

@@ -378,7 +378,7 @@ whatever an older build derived, indefinitely, and a deploy that corrects the
 parse would never reach the data. A version mismatch counts as drift, so the
 correction lands on the next boot without an operator having to know it happened.
 
-It is **5** as of Protocol 8 phase 7: the source files are now parsed in one
+It is **6** as of Protocol 8 phase 7: the source files are now parsed in one
 canonical label order whichever end read them. That matters because the parse is
 order-sensitive in one place — the decoration index keeps the first item id it
 sees for a type, and the two readers sorted a nested directory differently, so the
@@ -386,6 +386,15 @@ same tree could yield a different preview graphic depending on how it arrived.
 Identical files, a different answer for a handful of types: precisely what this
 number exists to push through the hash gate.
 
+That change was written as **5** while 5 was being released from `main` meaning
+something else — a spawn point keeping its `UniqueId` (v1.2.2) — so the Asset
+Bridge cutover renumbered it to 6. The renumber is the mechanism working rather
+than bookkeeping: an install that imported under v1.2.2 already stores 5, so a
+build declaring 5 for a *different* derivation would have been called current and
+the correction would have reached nobody already running. Two branches bumping
+the same counter for different reasons is the one way this gate can be defeated,
+and a merge is where it has to be caught.
+
 The **source fingerprint is taken over raw bytes** at both ends for the same
 reason. Hashing the decoded text would hash a UTF-8 *re-encoding* of the file —
 identical for valid UTF-8, and different for a file that is not, because an