Seed broadcast mod_revision baseline from etcd at startup
Addresses the correctness gap flagged in the review of the Txn-on- mod_revision change: if a freshly-started process's very first put hit GrpcDeadlineExceeded after server-side commit, the next retry's compare-failure was indistinguishable from a Carol-style restart (both have lastModRev==0). The old code's lastModRev==0 → re-peek branch would then double-deliver the message. Now broadcastMessages issues a one-time range query at startup (queryInitialModRev) and seeds lastModRevVar with whatever etcd thinks the current mod_revision of our key is — zero if the key does not yet exist. After this seeding the only way mod_revision can advance past lastModRev is via our own writes, so any compare-failure unambiguously means "we already delivered" and the caller pops. Side-effects: - putMessage no longer returns Bool; the re-peek path is gone. - The compare-failure branch traces a new BroadcastDeduped event carrying the previous and observed revisions, so an operator debugging packet-loss behaviour can see when the dedup actually fires. - The structurally-unreachable "compare failed AND range empty" case now `fail`s loudly rather than silently spinning — the surrounding race kills the node and a clean restart re-seeds against whatever state etcd has. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
