fix: session-lifecycle hardening — path-switch re-handshake (#36) + cert revocation (#41)

[vxfemboy]

Closes #36 and #41. Two independent session-lifecycle fixes in bin/yipd, both unblocked by the merged 9a/#91 rekey machinery. No wire change; yip-crypto/yip-wire/handshake.rs untouched; both are no-ops with membership off / no handshake in flight (2a/2b/2c byte-identical).

#36 — path-switch re-initiation half-opens a session

A path switch (Punch→Relay, Punch C1→C2) drew a fresh Noise ephemeral, so a responder already Established over the old path only replayed a cached_resp keyed to the original ephemeral → the initiator never completed → silent bidirectional black hole with the remote falsely "up".

• retarget_handshake preserves the in-flight ephemeral across a re-target (resend the existing init_pkt instead of begin_handshake minting fresh). started_ms is not reset (the 90 s give-up still bounds ephemeral reuse); last_sent_ms is reset (no redundant back-to-back Init); the relay branch clears endpoint, the direct branch re-stamps it (so handle_handshake_resp matches the reply). The two tick escalation arms call it.
• Responder-side relay adoption: 9a follow-up: relay-path session rekey (relay-only sessions get no forward-secrecy rotation) #91's path-consistency gate would otherwise make a direct-established responder drop the initiator's relayed Init. So a direct-established peer receiving a relayed cold-start retransmit (init_eph == cached_resp_init_eph — proven the original peer, harmless replay) adopts the relay for its egress and replays cached_resp, closing the headline scenario. A relayed Init with a new ephemeral against a direct peer stays 9a follow-up: relay-path session rekey (relay-only sessions get no forward-secrecy rotation) #91 fail-closed.
• Accepted tradeoff (rides with Handshake anti-replay (timestamp) + authenticated endpoint learning #34): an attacker replaying A's captured original Init over the relay forces a persistent direct→relay path downgrade (not a hijack — relay_wrap addresses the peer's registered node; current's keys unchanged) and degrades direct rekey. Documented in the spec.

#41 — cert revocation lag exceeds cert lifetime

A revoked (cert-expired, non-renewed) mesh member kept its Established session until process restart, because rekey and cold-start re-admission both re-used the session identity without re-checking the cert.

• drop_session — tear down a peer's session (remove its current/next/previous conn_tags from by_tag, revert to Idle).
• Rekey re-verify — a rekey Init must carry a currently-valid cert, else the live session is dropped.
• Re-admission gate — a tabled peer re-establishing must present a valid cert (without this, drop_session + the sweep only flap, not revoke).
• Periodic liveness sweep — throttled to once per rekey interval, drops any Established mesh peer whose cert has expired/been revoked — catching the revoked rekey loser that never sends an Init.
• A shared is_root helper exempts always-admit roots from all cert gates (roots are trusted via the signed root set, not a member cert). No-op when membership is None.

Verification

• 236 unit tests, cargo test -p yip-ca (4), clippy -D warnings, cargo fmt — all clean.
• netns money tests (both poll + io_uring drivers, run live under sudo):
  • run-netns-pathswitch-rehandshake.sh (2b: path-switch re-initiation can half-open a session (needs rekey/anti-replay) #36): A escalates punch→relay while B is direct-established → A converges over the relay (20/20 ping), DISTINCT_INIT_EPHEMERALS=1 across 6 Inits (the ephemeral is preserved — no cold-start churn), relay-forwarded>0.
  • run-netns-cert-revocation.sh (2c: cert revocation lag exceeds cert lifetime without session rekey (#9) #41): A's short-lived cert expires → B drops A's session within a bounded window (100% loss) and A cannot re-establish (the re-admission gate refuses the expired cert). (yip-ca sign-cert gains --secs N for minting the short-lived cert.)
• Regressions green: 2c discovery, 2c admission-reject, 9a follow-up: relay-path session rekey (relay-only sessions get no forward-secrecy rotation) #91 relay-rekey (0% loss, 10 rounds).
• Final whole-branch review: READY TO MERGE, no Critical/Important.

Known follow-up

For symmetry with the new gates, the pre-existing initiator-completion cert checks (handle_handshake_resp / relayed_handshake_resp) could also gain the is_root exemption — latent only (roots present valid certs in practice), out of this branch's delta. Filed separately.