feat(terminal): enumerate panes across every instance, as (kind, instance, pane) (#1152)

[fujibee]

Part of #1152 — priority 1 of the sweep: enumerate panes across every instance,
as (kind, instance, pane) triples. Independent of #1154; base is
integration/terminal-driver-v1.

A bare pane id is not an address

Measured on one machine, 2026-09-11, with two herdr instances running:

instance   response pane_id   shell_pid   who is actually there
jugemu     w1:p7              2727        one team's seat
oma        w1:p7              80649       a different team's seat

Enumerating both produced 52 rows in which w1:p1, w1:p2, w1:p4, w1:p5 and
w1:p7 each appeared twice. Two throwaway tmux servers showed the same with %0.
So nothing here emits a pane id on its own, and the instance that travels with it is a
socket path — the value that makes the row answerable again — not a display name.

This also means an id-echo canary cannot tell a wrong-instance answer from a right one:
both instances answer pane_id=w1:p7. That hole is reported separately against #1154.

The tmux half is resurrected, not rewritten

From PR #1147 (branch fix/1146-tmux-search-all-servers). Its socket enumeration and its
rule for when a server counts as dead were already written and measured there; the PR was
closed only because a different design was expected to replace it.

One verdict changed in the move. #1146's search asked "is this label unique across
every server?", so a server it could not read poisoned the whole answer. This op asks
"what is out there?", and for that question one unreadable server must not lose the
panes of the servers that answered. The hole is named and enumeration continues — same
mechanics, different verdict, because the question is different.

Four causes, four row kinds, none folded

<kind> <instance> <pane>   a pane was observed there
!  <kind> <instance>       that instance could not be read
!! <kind>                  that terminal's instance LIST could not be read
?  <kind>                  that terminal cannot enumerate at all

? and !! look identical from outside — no rows for that kind — and mean opposite
things to a caller: stop asking, versus retry.

Three things the measurements changed

• A socket proves nothing; it outlives its server. Only no server running /
  no such file or directory is evidence of death. Measured: a live non-tmux listener
  answers server exited unexpectedly, which is not that — so it becomes a named hole.
  A socket that is merely bound with nothing listening does report no server running
  and is correctly skipped. My first control was the second kind, so it exercised the
  stale path while claiming to test the unreadable one.
• An id that cannot answer must not become "this user has no servers" — the socket
  directory could not be named. Observed on this machine while directory services were
  degraded and id -un returned the bare uid.
• The glob runs in a subshell with failglob dropped. Measured, both interpreters:
  with a caller's shopt -s failglob and an empty socket directory, a bare
  for sock in "$dir"/* produced no output at all — the shell died at the expansion,
  before any row could be printed. nullglob does not cover it; failglob wins. And the
  case arm inside that substitution needs its leading (: bash 3.2 counts parens when
  parsing $( ), so a pattern's ) ends the substitution early.

Controls

15 tests, driving fake tmux and herdr binaries so the error texts and exit statuses
are the test's property rather than the runner's. The same four outcomes were also
produced against real tmux servers in one observation and agreed.

14 mutations, each with its own red: dropping the socket qualification → 5; dropping a
named hole → 1 each; widening the dead-pattern → 1; softening the uid guard → 1; removing
the failglob subshell → 1; the herdr session/pane strictness → 1 each; visiting
non-running instances → 1; dropping the kind → 2; folding ? into !! → 1; piping the
op's status instead of capturing it → 2; dropping the driver restore → 1. Clean: 0.

Two of those controls could not fail when first written, and the numbers above are
after fixing them. The "driver is restored" test loaded plain, which is the last
candidate — so a version with no restore at all left plain loaded and the test passed
on iteration order (measured: zero reds). And three negations were written
! cmd | grep -q … in non-final position, where bash cannot fail the test (#670); the
enforced-assertions checker named all three, run synchronously before asking for review.