Two seats can claim one pane and nothing reports it; --fix repairs each seat and leaves the collision

[fujibee]

Two different seats can hold placement records naming the same pane, and nothing
detects it. --fix reports each cell repaired, seat by seat, and the collision
survives untouched.

Found by a user noticing that two seats in one team appeared to be one session:
work dispatched to two names had been arriving at the same place all along.

Counting every record on this workstation by the ref it claims, eight refs are
claimed more than once. They are two different situations and only one is a
defect:

• The same seat registered in more than one team. One person, two rows, the
  same pane. Correct, and the placement guard already excludes a seat's own
  record by identity.
• Different seats naming one pane. A stale record from an old team pointing
  at a pane a live seat now occupies, and -- the case that prompted this -- two
  seats in the same team both naming one pane.

Why the existing guard does not cover it

The guard added for #1114 refuses a write onto a pane another record claims. It
says nothing about records that already collide, and collisions are exactly what
a machine accumulates: panes are reused, teams are abandoned, seats are renamed.
Nothing sweeps.

Why --fix does not either

--fix walks seats and repairs cells within each seat. It has no cross-seat step,
so two seats can each be reported renamed_and_verified while sharing a pane. The
per-seat report is true and the fleet-level statement it implies is not.

In the case that prompted this the label route could not help: both panes had lost
their labels, so the resolution falls into the documented keep-the-record branch
and the duplicate is preserved. That branch is right on its own terms -- nothing
settled the question -- but the result is that the one command meant to make every
seat correct leaves two seats pointing at one pane and says nothing.

Proposed

Report first. A cross-seat check that names the colliding rows costs one pass over
records already being read, and turns an invisible state into a visible one. What
to do about a collision needs more thought than this issue has: for a stale row
from a dead team the answer is probably to drop it, and for two live seats it is
probably to refuse and tell the user, since guessing which one belongs there is
how the wrong pane gets written in the first place.

Worth separating from #1140 and #1131. Those repair one seat against evidence.
This is about a property that only exists between seats, which is why per-seat
repair cannot see it.

[fujibee]

Measured follow-up, and it is worse than a collision: both seats are gone.

The two rows naming one pane belong to seats whose sessions no longer exist.
Their message bridges are still running -- two live pids -- so messages addressed
to them are accepted and nothing acts on them. Their recorded pane is empty: no
agent, no session, no label.

record        seat A -> <pane>     seat B -> <pane>     (same pane, both stale)
that pane     agent: none   session: none   label: none
bridges       both pids alive
bridge threads  neither appears among the 18 live panes' sessions

The user's report that started this was "work dispatched to two names was
arriving at one place." The measurement says otherwise: it was arriving at
neither. The rows point at a pane nobody occupies.

What this adds to the issue

--fix reported these seats repaired. That report is about the pane the record
names, and it is true of that pane; it says nothing about whether the seat is
there, because nothing checks. So the state that reads as healthy -- every cell
green, renamed_and_verified -- is compatible with a seat that has been gone for
days.

The collision described above is one symptom of the same absence. Two rows can
name one pane because no row is ever checked against who is actually in it, and a
row can name an empty pane for the same reason.

Adding to what this issue proposes: the cross-seat report is worth having, and
alongside it the cheaper check -- does the pane this record names currently host
anything at all? A stale row pointing into the void is not a subtle state to
detect, and it is the one that silently swallowed dispatched work.

Not proposing an automatic sweep here. Deciding that a seat is dead and dropping
its row is the kind of judgement that produced the wrong record in the first
place; saying plainly that the pane is empty is not.