docs: rc3 is on gh alone, not "all three remotes"

FOUND BY RUNNING THE COMMAND THE CLAIM IMPLIED. `git ls-remote --tags` against
each of gh, origin and gitea: v0.1.0-rc3 exists on gh ONLY. origin and gitea
carry v0.1.0-rc1 and v0.1.0-rc2 and nothing else.

The claim originates in aa4e901's commit message and was repeated from there
into context/code/tooling.md and, an hour ago, into RELEASING.md by me -- three
copies of a fact nobody had asked a remote about. That commit message is
superseded on this point and cannot be corrected, which is the case
context/design-principles.md section 6 makes for not letting an argument live
only in one; the correction is therefore recorded in tooling.md, naming the
commit.

The irony is local. The false claim sat two paragraphs from the sentence "an
empty log is a statement about RETENTION, not about history", which is the same
failure in the same section: a fact about a remote asserted instead of asked.
Writing that sentence did not stop me repeating the neighbouring instance of it,
which is the more useful half of this commit.

What it changes and what it does not. The rule is untouched -- a published tag
is not moved, and gh is the remote carrying the release machinery, so the
preflight's reason for existing is unaffected. What moves is the SCOPE of any
cleanup, from three remotes to one, and that is precisely the sort of detail a
reader following RELEASING.md at 2am would act on. RELEASING.md now says which
remote and tells the reader to run ls-remote rather than assume the mirrors
agree -- they did not.

No version bumped, no tag cut, no tag deleted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FC2jVn8Au7E9JPkw6bwXXH

RELEASING.md

@@ -12,7 +12,7 @@ no user benefit.
 
 **Bump the version and commit it BEFORE you tag.** `dist` matches the tag
 against the root package's version and refuses when they disagree — and by the
-time CI tells you, the tag is public on three remotes and a published tag is not
+time CI tells you, the tag is already published and a published tag is not
 moved. Every step below exists to put that check before the irreversible one.
 
 ## Cutting a release
@@ -56,14 +56,15 @@ moved. Every step below exists to put that check before the irreversible one.
 
 ## When a tag has already been pushed against the wrong version
 
-**Leave it dead and cut the next one.** Do not move or re-push the tag: all
-three remotes carry it, and a published tag that changes meaning is worse than
-one that never built. Bump to the next version, commit, run the preflight, and
-tag that.
+**Leave it dead and cut the next one.** Do not move or re-push the tag: it is
+already public, and a published tag that changes meaning is worse than one that
+never built. Bump to the next version, commit, run the preflight, and tag that.
 
-`v0.1.0-rc3` is the standing example — pushed while every crate still said
-`0.1.0-rc2`, so `dist` refused and the four jobs behind `plan` skipped. It has
-no GitHub release and is left as it is.
+`v0.1.0-rc3` is the standing example — pushed to `gh` while every crate still
+said `0.1.0-rc2`, so `dist` refused and the four jobs behind `plan` skipped. It
+has no GitHub release and is left as it is. (It is on `gh` **only**; `origin`
+and `gitea` carry `rc1` and `rc2`. Check with `git ls-remote --tags <remote>`
+rather than assuming the mirrors agree — they did not.)
 
 A tag with no release is not a tag to clean up on the way to cutting one;
 whether the stale `rc` tags are ever removed is a separate decision, and not a

context/code/tooling.md

@@ -341,7 +341,7 @@ autogenerated mechanism, `README.md` §Installation describes the result, and
 plan. So the preflight is the second half of the fix; `RELEASING.md` is the
 first.
 
-**What happened.** `v0.1.0-rc3` was pushed to all three remotes while every
+**What happened.** `v0.1.0-rc3` was pushed to `gh` while every
 crate still said `0.1.0-rc2`. dist matches a tag against the root package's
 version, refused with *"This workspace doesn't have anything for dist to
 Release!"*, and the four jobs behind `plan` skipped. **Nothing was wrong with
@@ -384,12 +384,26 @@ a tag look alike at a glance and mean opposite things.
 answer in its own error text — *"`--tag=v0.1.0-rc2` will Announce: improvise"*.
 The problem is not the message, it is **when** it arrives: a tag is public and
 immutable by the time CI reads it, so the repair is a new version rather than an
-edit, and the tag that failed stays on three remotes forever. A check that runs
+edit, and the tag that failed stays published forever. A check that runs
 after the irreversible step is a check in the wrong place, however good its
 message. So the preflight runs *before* tagging and prints the tag command only
 once it has passed — the honest path made the easy one, the same shape as
 `Basis` having no public constructor (gotcha 43).
 
+**"All three remotes" was wrong, and it is worth saying which way.** `rc3` is on
+**`gh` alone**; `origin` and `gitea` carry `rc1` and `rc2` only
+(`git ls-remote --tags <remote>`, all three checked). The claim came from
+aa4e901's commit message and was repeated from there into this section and into
+`RELEASING.md` before anyone ran the command — **that commit message is
+superseded on this point and cannot be corrected**, which is why
+`context/design-principles.md` §6 says an argument must not live only in one.
+The irony is local: it sat two paragraphs from *an empty log is a statement
+about retention, not about history*, which is the same failure — a remote-shaped
+fact asserted rather than asked. It changes nothing about the rule (a published
+tag is not moved, and `gh` is the remote with the release machinery) and
+everything about how much cleanup there would be, which is exactly the kind of
+detail a 2am reader would act on.
+
 **The primary check is textual and the `dist plan` run is a second opinion.**
 An absent `dist` must not read as a pass, so the script says which of the two
 ran. It also tolerates a locally-installed dist whose version differs from the