Build a fully peer-to-peer WireGuard mesh

[flo2517]

Establish WireGuard tunnels between workloads by direct peer-to-peer key exchange, removing the Control Plane from the packet path and from the role of configuration authority. Today control-plane/internal/wireguard/wireguard.go is the central party that issues and distributes peer configuration; ADR-010 makes those overlays short-lived and lease-gated, and that property must survive decentralization rather than being traded away for it.

Blocked by: ADR-017 (see ADR-012 §6) — no implementation before acceptance. Depends on #36, because peer authentication cannot rest on a Control-Plane-issued allowlist once the Control Plane is no longer in the path.

Acceptance criteria:

• ADR-017 defines peer authentication without a central introducer, and the bootstrap path for a node that has never spoken to any peer;
• a tunnel is established only when a finalized on-chain lease authorizes that pair of workloads to communicate — the lease gate from ADR-010 is preserved, not relaxed;
• public key exchange is authenticated and replay-resistant, reusing the subject/sequence/deadline pattern of ADR-012 §4 rather than a new scheme;
• key rotation and revocation propagate without a central push, with a bounded and stated convergence time;
• a revoked or expired peer loses connectivity within that bound, and failure to converge is surfaced explicitly rather than leaving a stale tunnel open;
• the Provider Agent still never talks to the chain directly unless ADR-017 explicitly lifts that rule and states the new trust boundary;
• rollback: Control-Plane-configured WireGuard remains operable for one release, per ADR-012 §7;
• tests cover establishment, lease expiry mid-session, revocation, a peer advertising a key it does not hold, a partitioned peer, and an unauthorized peer attempting to join the mesh.

---

Original request (FR, preserved verbatim):

Implémenter un échange de clés publiques et une configuration de tunnel WireGuard sans passer par un serveur central.