`TidalDBClusterQuorumLag` sat CRITICAL all session against the live three-voter
cluster while every region reported lag 0 and every per-peer ship queue was
empty. Two independent defects fed it:
- `observe_ship` bumped `relay_last_seq` on every batch ship while
`relay_durable_seq` only moved when a signal write completed. The two are
documented as a subtractable pair, so a shipping-but-not-committing node
reported the whole relay log (13.3M events) as quorum lag. The ship path now
feeds only its own per-peer queue-depth gauge; the pair has one writer.
- `set_frontier_gauges` published `CommitIndex::committed()` verbatim, but that
returns 0 as a SENTINEL for "no quorum information in this term yet". It now
publishes both halves or neither, and every satisfied `await_quorum` -- not
just signal writes -- refreshes them, so item and embedding workloads keep
the pair live.
Regression test asserts a busy ship loop leaves both halves at 0 (lag 0, not
13.3M) and that the single writer still moves them together.
Also excludes the `tmp` emptyDir from velero fs-backup: three 0-byte
PodVolumeBackups a night whose only other outcome is failing the whole fleet
backup when a scratch file vanishes mid-snapshot.
12c7edc374