docs: a tip SHA goes stale in the commit that writes it

The zoom lane recorded `1e054f7` as the authoritative tip. Committing
that line advanced the tip to b645fe7, so the claim was false before it
was pushed --- self-invalidating, not merely out of date.

The ledger already says this, twice: the docs-absorption and
signal-integrity lanes both note that any edit to their block advances
past whatever SHA it records, so the REF is the thing to trust. I wrote
a new lane without following the convention the file states about
itself.

Removes the SHA and says why, so the next lane inherits the reason
rather than the rule alone.

The base SHA stays. 218d2e7 is a merge commit that already exists and
nothing here can move it --- it is a fact about where the branch
started, not a claim about where it is.

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

docs/active-work.md

@@ -304,8 +304,9 @@ correction from #171 and #215 — so the row below was filled in rather
 than invented.
 
 - **Branch `gui-zoom`**, base `githubsucks/main` @ `218d2e7` (the #219
-  merge). Pushed; `githubsucks/gui-zoom` is the authoritative tip, at
-  `1e054f7`.
+  merge). Pushed; **`githubsucks/gui-zoom` is the authoritative tip** —
+  the ref, deliberately not a SHA, since writing one into the commit
+  that updates this lane makes it stale in that same commit.
   Recover: `git fetch githubsucks && git checkout gui-zoom`.
 - **Framing `docs/gui-zoom-framing.md` revision 5**, approved after
   four review rounds; revision 5 adds §3.2 for a finding raised against