#3039 Serve audit: a durable sink write that times out is retried while the first call is still pending, so the store can hold duplicate sequences

Summary

AuditEmitter (src/domain/serve_audit/audit_emitter.ts) races each durable sink write against a 30s timeout but does not cancel or track the underlying call. When a durable write times out, the sink cursor stays put and the same events are written again on the next drain while the first call is still pending.

Concrete case: WalSink.write appends a WAL segment and then awaits StoreSink.write, which awaits a put on a remote control-plane store once a batch is full. If that put hangs for more than 30s, the emitter times out and appends a second WAL segment holding the same events. When the hung writes finally land or the WAL is replayed, the store holds duplicate events with the same sequence, and swamp audit verify reports a broken chain.

This predates swamp-club#2988, where the retry happened when the next event arrived. The fix for #2988 adds a fixed 1s durable retry timer, so it now recurs roughly every 31s for as long as the hang lasts, even with no traffic.

Why it was not fixed in #2988

Non-durable sinks now have a one-write-in-flight guard. Applying the same guard to durable sinks stops the duplicates, but a durable write that never settles would then block the durable path until restart. That trade-off needs its own design decision.

Options

• Guard durable writes like non-durable ones, plus an escape hatch for a write that never settles (for example treating the sink as failed and surfacing it to fail-secure mode).
• Pass an AbortSignal through AuditSink.write so a timed-out write is actually cancelled.
• Make the store and WAL idempotent on sequence so a duplicate write is harmless.

Raised by both agent reviews on the #2988 change.