relay: skip TTL deadline bump for known-permanent channels (T1a write-amp)

[tlongwell-block]

What

Skip the bump_ttl_deadline write on the hot ingest path when the channel is known-permanent (ttl_seconds IS NULL on the already-prefetched channel row).

Every stored channel-scoped event currently executes bump_ttl_deadline, whose predicate matches zero rows on permanent channels — a wasted write-shaped round trip and implicit transaction per message. This is T1a of the write-amplification workstream.

Safety

• Skip only when the prefetched row positively shows ttl_seconds IS NULL. A missing row (kind:9007 pre-create, transient get_channel error) still bumps — an ephemeral channel can never archive early due to a failed prefetch.
• A concurrent update_channel that sets a TTL resets ttl_deadline itself, making the skipped bump redundant by construction (race is benign in both directions).

Measured impact (local integration benchmark, real relay binary + PG17 + Redis)

Scenario A (zero push leases), net Postgres commits per accepted message, same DB container/channel, quiescence-gated windows, idle-rate subtracted:

qps	baseline (main @ 8908bd6)	T1a	delta
5	11.13	10.22	−0.91
10	11.09	10.07	−1.02
30	11.00	10.02	−0.98
50	10.96	9.99	−0.97
100	11.01	9.99	−1.02

Exactly the predicted ~1 commit/message, flat across load.

Testing

• Live functional probes on the built binary: permanent channel posts no longer touch ttl_deadline; ephemeral-channel expiration still works, including a permanent→ephemeral flip during traffic.
• cargo test -p buzz-relay green except the known mesh_demo failure that is also red on untouched main.

Part of the write-amp series; sibling PR: T2a audit batching. Larger follow-up (T1b: push-queue skip at zero leases) targets ~5 of the remaining ~10 commits/msg.

[tlongwell-block]

Blocking race in the TTL skip. The prefetched channel_row is not fresh at the point of the skip; it is read before event persistence/side effects. Concrete interleaving:

1. ingest reads ttl_seconds = NULL and sets known_permanent = true;
2. concurrent kind:9002/update transaction sets ttl_seconds = 600 and ttl_deadline = t1 + 600;
3. this ingest stores its event later at t2 and skips bump_ttl_deadline;
4. deadline remains t1 + 600 rather than t2 + 600.

That violates the existing invariant immediately above the changed code: every successfully stored channel-scoped event keeps the channel alive. update_channel setting a future deadline does not make the later bump redundant; it only ensures the deadline is non-null/future. The evidence script checks only ttl=600 and deadline > now, so it cannot detect this lost extension.

Please close the stale-positive race and add a barrier-forced test asserting the deadline reflects the event ordered after the TTL transition (not merely that it is future). The optimization must remain fail-safe toward bumping when permanence may have changed.

Review source: exact PR head 2515f25c9c1dddbf56bf986cf650008f411a35c7; cargo test -p buzz-relay reproduced 687 pass / the disclosed single mesh_demo failure.