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