feat(quic): GEK proof and mutual authentication — closes C6

Phase 11.5.4/5/6 — finding C6, the last open critical finding.

QUIC ran a JWT-only handshake: a forged or stolen token reached the node and
could inject chat without ever holding the group key. It now runs the same
challenge/response as WebRTC through meshbay_common.handshake — client nonce,
role-bound length-prefixed transcript, GEK proof, and the node proving itself
with a GEK proof plus an Ed25519 signature over the transcript (C3).

11.5.6 channel binding, resolved by spike and then by two findings the spike
could not predict:

  * aioquic 1.3.0 exposes no RFC 5705 exporter, and the peer certificate only
    via a private attribute. The server reads its own certificate from disk, so
    no internals are touched on that side; the client's access is guarded and
    fails loudly if an upgrade moves it.
  * A RESUMED TLS session carries no certificate — aioquic does not re-send it,
    so there is nothing live to bind to. The anchor therefore travels with the
    session ticket, which is sound because the ticket is cryptographically
    derived from the handshake where that certificate was presented.
  * The anchor had to travel with the ticket rather than live on the client
    object: resumption constructs a fresh client, so an instance-level cache
    was silently useless. Caught by the resumption test, not by inspection.

Both paths refuse rather than degrade. No certificate and no cached anchor
means the handshake fails; it never falls back to an unbound proof, which would
silently drop MitM detection (L4).

QuicChunkClient gains a peer_cert_der property and constructor argument,
mirroring how session_ticket is already carried by the caller.

Tests: 9 quic/multi-group, full node+common suite green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

0 files changed, 0 insertions, 0 deletions