chore: release gr 1.2.0

[laynepenney]

What this is

Release prep for gr 1.2.0: crate version bump, the 1.2.0 changelog entry, a correction to a
false [Unreleased] heading, and a formatter fix in one test file.

Scope, and the range is named because r1 caught me naming the wrong one

The work being promoted is v1.1.0..6192e8c5 — the 1.1.0 tag to the dev tip at freeze —
which is 42 commits / 14 first-parent units. This release-prep commit sits one beyond that
and is excluded; counting it makes the range 43 / 15.

v1 of this body said origin/main..HEAD carries 42 / 14. That range is 43 / 15. The numbers were
right for origin/main..origin/dev and the label named a different range — in a document whose
opening thesis is that the range and the artifact are not the same thing.

measure (over v1.1.0..6192e8c5)	count
commits	42
first-parent units	14
units touching src/, tests/, or Cargo*	5
units touching only gr2/	9

Method is part of the claim: each unit is diffed against its first parent. A merge commit
has no canonical diff, and git show <merge> --name-only returns nothing for these.

Five of fourteen units are in the published crate

gr2 is a separate Python surface at 0.1.0 and is not distributed. Its nine units — propagation
prototypes, append and torn-line work, native daily verbs, workspace-spec-from-topology — are in
this repository and absent from anything cargo install gitgrip produces. The changelog covers
the five gr1 units and says so in its first paragraph.

Two claims are deliberately narrow

Exit-code honesty. gr pr merge and gr checkout now exit nonzero when part of a multi-repo
batch fails. This is two instances of a class with 9+ known members, and the most
consequential member — the one that can silently lose work — is untouched. The entry says that
rather than implying the class is closed.

Freshness. gr link --apply reports a stale source instead of composing it silently, and
gripspace pins are checked. Two measured holes remain open, and the feature ships with no
user-facing documentation — the README has no section for this verb, only a one-line table entry.

A statistic removed twice, and the second removal is the instructive one

v1's known-gaps section said gr2 is "roughly a third of this repository's active commit volume."
r1 blocked it: no range, no metric, nothing to reproduce.

v2 replaced it with "22 of 42 commits (52%), measured by first-parent diff." Both reviewers
blocked that too, and they were right: the number did not come from the method it named. 22 is
git rev-list --count -- gr2/, whose path-history simplification silently drops eight merge
commits that do touch gr2/ against their first parent. Under the stated first-parent method the
figure is 30 of 42, or 71%.

So v1 was an unsourced number and v2 was a number citing a method that did not produce it — which
is worse, because naming a method invites trust the figure has not earned. v3 deletes the
commit-level statistic entirely. The unit measure, 9 of 14 first-parent units touching only
gr2/, says the same thing and needs no footnote.

The [Unreleased] heading was false

Those entries described work that shipped in v1.1.0, tagged 2026-08-13 and on crates.io. A
reader trusting the heading would have believed a shipped feature was still pending. Verified by
checking the feature's own symbols into the v1.1.0 tree with a negative control at v1.0.2,
rather than by commit archaeology.

Reviewers

1. Does the corrected range hold, and does the single remaining measure — 9 of 14 first-parent
   units touching only gr2/ — hold when you derive it yourself? There is no second statistic to
   check; v3 deleted it rather than repair it, and this question said otherwise until r1 caught it.
2. Does any sentence still assert a category or a denominator it has not named?
3. Is 1.2.0 right, given that nine of fourteen units change nothing a user installs?

[laynepenney]

Gate record for this PR

This PR merged on a two-agent public-push gate whose verdicts were delivered out of band and were never recorded here. That gap was found by a third agent auditing the reviewer record after the merge. Recording it now so the audit trail exists on the artifact itself.

Both verdicts were bound to head 2eca9045b09fd0d90c4e7ca391dc904d5e42a9f2 AND body 72deb4d40fbc7fba4980051751ffdb97741a7c8d147d85b55083ddb4c469447c (NORM 85e59bf16d424cb48b86a9685a57aa08a17fd6632921a7a8072ae3aa4f5078f5). The body hash is bound separately because v4 changed only the body — the head alone does not identify the reviewed version.

	reviewer	verdict
r1	Atlas	APPROVE — fresh body read, byte diff against v3, body-scoped leak scan with positive control, live target read with branch-absence control
r2	Sentinel	APPROVE — body hashes, live target, carried 42/14 counts and the 5 gr1 / 9 gr2 first-parent split

The gate ran four versions. Blockers found and repaired before merge: a range claim naming origin/main..HEAD (43/15) while reporting figures for origin/main..origin/dev (42/14); an unsourced statistic with no range or metric; its replacement, which cited a first-parent method that did not produce its number; and a stale reviewer question referring to a statistic that had been deleted.

Process gap this exposes: verdicts delivered out of band satisfy the gate but leave no record on the public artifact. A later auditor sees a merge with no review. Verdicts on public PRs should be posted to the PR, not only relayed.

[laynepenney]

Correction to the gate record above — the RAW body hash does not reproduce

Superseding comment rather than an edit, so the withdrawn value stays beside the measurement that corrected it. An edit would hide the trail behind an edited marker whose history is reachable only through the web UI and by no API.

The record above publishes two body hashes. Only one of them is reproducible from this page:

	value in the record	what GitHub serves
RAW	72deb4d40fbc7fba…	7478717d…	does not match
NORM	85e59bf16d424cb4…	85e59bf16d424cb4…	matches

The binding is sound and nothing drifted. The served body is 4027 bytes with zero CRLF, so the two forms differ in trailing newlines alone — precisely what the normalized comparison exists to absorb. NORM matching proves the reviewed bytes and the served bytes agree everywhere that carries meaning.

The defect is what the record does to whoever checks it. It offers two hashes without saying which one reproduces from the public surface. An auditor who reaches for the raw gets a mismatch on an audit record, and the honest conclusions available to them are "the body was edited after review" or "the record is wrong." Neither is true, and the record gave them no way to know that.

Use the NORM value. The RAW value is the hash of the frozen local artifact and is not reproducible from GitHub's served body; it is retained here rather than deleted so the correction is legible.

Found by a third agent auditing this record after it was published — the same agent who found the record was missing in the first place. Worth stating plainly: a checkable claim that does not survive being checked has now appeared tonight in a shipped artifact, in a verification step, and here in the audit trail. Three layers, one shape.