WireMesh v0.10.4

WireMesh v0.10.4

Patch release: the controller now directs a rotation only when the gateway's newest key row is still awaiting its key (PR1b, design Rev 1.40).

Fixed

• controller: after a gateway aborted a rotation cleanly, the aborted epoch's pending row (sentinel pubkey) survived until ABORT_AFTER, and Broker::send_rotate_if_pending selected the FIRST sentinel row in ascending epoch order — so the next Admin.RotateKey directed the stale orphan epoch instead of the one it had just created; the gateway rotated to the stale epoch, refused the correct directives as in-flight, and the new epoch was never served. The broker now takes the max-epoch row over all rows and directs it only if it is a sentinel. Filter order matters: "highest sentinel" alone would later direct the orphan and rotate the fabric backwards, deleting the newer key.

Evidence

Six unit cases incl. the backwards-rotation guards; two falsification runs (.find() revert; filter-then-max) each redding exactly the cases that discriminate them; full controller suite green; no new clippy diagnostics.

Unchanged

Automatic key rotation stays off by default. Follow-ups filed for Phase C: an orphan pending row still suppresses timer-driven rotation for that gateway for up to 300s; epoch monotonicity guards on both sides.

Full diff: v0.10.3...v0.10.4