gig-log: it was never ten sessions in a row, and the real count tells a better story

A subagent counting cc records per log caught the claim; confirmed
independently. Nine straight zeros Sep 6-22 (no mbind at all -- the 'Launch
Control XL' name era), then 35 in gig-20260923-101102, then 0 in the 14-hour
gig-20260923-103812, then 145 tonight.

So the September name fix WORKED and the 10:11 session proves it. The 14-hour
session recorded nothing for a different reason: it bound a live address that
later died under it when the driver republished. Two failures, not one, and
only the second -- liveness -- is still open.

This is also independent evidence for the corrected diagnosis: a resolver that
could only ever pick the wrong port would not have produced 35 records an hour
earlier. Worth having in the file, because 'ten sessions of silence' invites
the wrong fix.

TODO_GIG.md

@@ -713,7 +713,7 @@ match the new track's *default* instead of the sound's *state*.
 ### And the reason this had to be read off the driver's journal: gig-log binds ONCE and never re-resolves
 
 Zero `cc` records in `gig-20260923-103812.jsonl` — 16227 `s` samples, 28 `eval`,
-9 `track`, and **0 `cc`**. That is the tenth session in a row with no MIDI. The
+9 `track`, and **0 `cc`**. The
 `mbind` line names the culprit:
 
 ```
@@ -761,8 +761,19 @@ records. Bound once at 10:38 and deaf for fourteen hours.
       `HUI` is already excluded — `and " FB" not in line`. Then restart gig-log
       and confirm within seconds of moving one knob that `cc` records appear.
       **Verify by the records, never by the header**: `"midi": true` has been
-      lying for ten sessions because `available()` only asks whether aseqdump is
-      installed.
+      lying for every one of them, because `available()` only asks whether
+      aseqdump is installed.
+
+**COUNT CORRECTED 01:55** (a subagent caught it, and the real numbers tell a better
+story). `cc` records per session: **nine straight zeros** Sep 6 → Sep 22 (no `mbind`
+at all — the "Launch Control XL" name era), then `gig-20260923-101102` with **35**,
+then `gig-20260923-103812` with **0**, then tonight's `gig-20260924-005926` with
+**145**. So it was never "ten in a row": the September name fix **worked**, and the
+10:11 session proves it. The 14-hour 10:38 session recorded nothing for a *different*
+reason — it bound a live address that later died under it. Two failures, not one, and
+the second is the liveness bug that is still open. This is also independent evidence
+for the corrected diagnosis above: a resolver that could only ever pick the wrong
+port would not have produced 35 records an hour earlier.
 
 ## Thu 24, 01:20 — the cap is thermal-pilot's rung-1 FLOOR, proven by the rig's own hand