2c: cert revocation lag exceeds cert lifetime without session rekey (#9)

[vxfemboy]

Context

Whole-branch review of milestone 2c. The spec states "revocation = cert expiry (bounded lag = cert lifetime)"; the review found this is optimistic without session rekey.

Problem

A runtime cert-admitted peer stays in the peer table and its Established Noise session persists for the daemon's lifetime (no rekey / session-expiry — #9 deferred). A fresh HandshakeInit from an already-tabled peer is admitted by static-key match WITHOUT re-checking the cert. So revocation-by-non-renewal only fully takes effect on process restart of the peers holding the session — a revoked member keeps its live sessions until then.

Fix direction

Tie to the session-rekey milestone (#9): on rekey (~120s), re-verify the peer's current cert (require a fresh valid cert in the rekey handshake), so a revoked/expired member's session drops within a rekey interval rather than at process restart. Optionally add a periodic cert-liveness check on Established mesh peers.

Scope

Depends on #9 (rekey). Documented residual for 2c ("a compromised member is a full peer until its cert expires AND its sessions rekey/restart").

[vxfemboy]

Fixed by PR #95 (session-lifecycle hardening, merged to main). #41 got three enforcement mechanisms: cert re-verify on rekey Init (drop session on fail), a re-admission cert gate on cold-start (a revoked member can't reconnect by static-key match), and a throttled periodic cert-liveness sweep (drops any Established mesh peer whose directory cert expired; roots exempt). Proven end-to-end by the netns money test (run-netns-cert-revocation.sh): a member whose cert expires loses its session within a bounded window and cannot re-establish. (The PR body's 'Closes #36 and #41' only auto-closed #36 — closing this manually.)