docs: a shared failure signature is not a shared cause (my own overreach)

The paragraph added two commits ago said this version/tag disagreement "has been
hit three times across two releases". I did not check that. What the tag history
actually supports is narrower, and the gap is the same asserted-not-asked error
the paragraphs on either side of it exist to correct -- which is why this is a
commit rather than a quiet edit.

WHAT IS VERIFIED. All three failed tag pushes carry the identical signature:
plan failure with build-local-artifacts, build-global-artifacts, host and
announce all skipped. Checked per job through `gh run view --json jobs` on each
of the three runs, not inferred from the 14s/21s durations, which was how the
claim got made.

WHAT IS NOT. Only rc3's CAUSE was reproduced, by running dist plan against the
tag. rc1's logs aged out at 90 days and cannot be read now, and its two failures
sit on commits titled "feat: cargo dist info" and "chore: update version" --
initial setup, where plan could as easily have failed on an incomplete dist
config as on a version/tag mismatch. A shared signature is evidence of a shared
shape, never of a shared cause.

So the honest claim is: this failure SHAPE has cost four pushes across two
releases, and the one time anyone diagnosed it, it was the version/tag
disagreement. That is ample reason for RELEASING.md and for a check before the
irreversible step. It is not a claim that the same mistake was made three times,
and the paragraph now says which half is which and names its own first draft as
the error.

Also dropped: an attribution of the earlier failures to a particular person,
which the run list does not establish and which the argument does not need.

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

context/code/tooling.md

@@ -365,17 +365,29 @@ history**; the artefact a run *published* outlives the run, so ask the releases
 before asking the runs. "The four jobs behind `plan` skipped" is true of the
 rc3 run alone and must not be read as "no release has ever been built".
 
-**And the mistake is recurrent, which is the real argument for a written
-procedure.** `gh run list --workflow=release.yml --event=push` keeps the whole
-tag history, and it reads: rc1 **failed twice** (14s each) before succeeding on
-the third push (3m25s), rc2 succeeded first time (3m9s), rc3 failed (21s). So
-this same version/tag disagreement has been hit **three times across two
-releases** by the person who set the workflow up. A one-off justifies a note; a
-third occurrence justifies `RELEASING.md` and a check that runs before the
-irreversible step. The signature is worth memorising because it is so cheap to
-read: **`plan` fails in ~20s with four jobs skipped** (verified on the rc3 run:
-`plan: failure`, `build-local-artifacts`, `build-global-artifacts`, `host` and
-`announce` all `skipped`), where a real build takes about three minutes. Note
+**A tag push has failed this way before — and how much that proves is worth
+being exact about.** `gh run list --workflow=release.yml --event=push` keeps the
+whole tag history, and it reads: rc1 **failed twice** (14s each) before
+succeeding on the third push (3m25s), rc2 succeeded first time (3m9s), rc3
+failed (21s). All three failures carry the **identical signature** — `plan:
+failure` with `build-local-artifacts`, `build-global-artifacts`, `host` and
+`announce` all `skipped` — checked per job, not inferred from the durations.
+
+**A shared signature is not a shared cause, and rc1's is not knowable now.**
+Only rc3's was reproduced (`dist plan --tag=v0.1.0-rc3`); rc1's logs aged out at
+90 days, and its two failures sit on commits titled *"feat: cargo dist info"*
+and *"chore: update version"*, i.e. during initial setup, where `plan` could as
+easily have failed on an incomplete `dist` config. So the honest claim is: this
+failure **shape** has now cost four pushes across two releases, and the one time
+anyone has diagnosed it, it was the version/tag disagreement. That is ample
+reason for `RELEASING.md` and a check before the irreversible step, and it is
+**not** a claim that the same mistake was made three times — a first draft of
+this paragraph said exactly that, from the durations alone, which is the same
+asserted-not-asked error the two paragraphs around it correct.
+
+The signature is worth memorising because it is so cheap to read: **`plan` fails
+in ~20s with four jobs skipped**, where a real build takes about three minutes.
+Note
 the workflow also triggers on `pull_request`, where it plans without a tag and
 passes in ~20s — so a *green* 20s Release run on a PR and a *failed* 20s one on
 a tag look alike at a glance and mean opposite things.