feat(cli): v3.1 multi-hop runtime — circuit client + relay rendezvous

Completes v3.1 multi-hop / onion routing (2 hops: client → entry-relay →
exit-server). Combined with the scaffold commit (6c14c0d), the property
holds: entry-relay knows the client IP + client_id but cannot decrypt the
data; exit knows the destination but sees the relay's IP as source.

- aura-cli::circuit: dial_circuit(&[entry, exit], proto_cfg, udp_opts) →
  CircuitConnection. Connects to entry as a normal UdpClient, sends an
  ExtendBridge control envelope, awaits CircuitReady, then runs a SECOND
  Aura handshake to the exit through a local loopback UDP proxy — the
  forwarder ferries datagrams between that proxy socket and the outer
  relay PacketConnection. The inner handshake therefore authenticates the
  EXIT cert (verified by the integration test asserting
  circuit.peer_id() == "localhost-exit"); the relay never sees the inner
  session keys.
- aura-cli::relay: rendezvous(conn, whitelist) -> Bridged{bridge} |
  Fallback{first_pkt} | Refused. 2-second window after handshake to receive
  ExtendBridge. Whitelist enforced; CircuitFailed on miss. Empty whitelist
  logs a warning and runs open. Timeout / non-control → Fallback so the
  same server can be both relay (for circuit clients) and exit (for direct
  clients) simultaneously.
- aura-cli::client: when [client.circuit] enabled → dial_circuit; falls
  back to normal aura_transport::dial when disabled.
- aura-cli::server: relay rendezvous wired before pool/CRL/router path.
  run_bridge spawns two forwarder tasks (conn↔bridge UDP socket).
- 3 integration tests: end-to-end (with peer_id assertion), whitelist
  rejection, back-compat (relay disabled → Err). 3 unit tests in relay.rs.

Workspace: 253 tests passed (247 baseline + 6 new), clippy -D warnings clean,
fmt clean. No new workspace deps. All 28 tracked tasks (v1 + v2 + v3.1) now
complete.

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

config/server.toml.example

@@ -119,3 +119,28 @@ knock_secret_source = "ca_fingerprint"
 enabled = false
 mean_interval_ms = 500
 jitter = 0.5
+
+# v3.1 multi-hop / onion routing: turn THIS server into an **entry-relay** that can splice an
+# inbound client connection to a downstream **exit-server**. Right after the inner Aura
+# handshake completes, the relay waits up to 2 seconds for the client to send a single
+# ExtendBridge control envelope describing the downstream exit's IP:port. When the address is
+# on `allow_extend_to`, the relay opens a `connect()`ed UDP socket to that exit, replies
+# CircuitReady, and forwards every byte verbatim — the inner client↔exit handshake travels
+# through the relay opaquely, so the relay never sees destination IPs or plaintext bytes.
+#
+# The connection in that role is NOT registered with the IP pool / [`ServerRouter`]; bridged
+# peers do not consume a tunnel address. If no ExtendBridge arrives within 2s the connection
+# falls back to the normal VPN-client path (so one server can serve both roles on one port).
+# v3.1 only supports the UDP transport for relay hops.
+#
+# Omitting the whole [server.relay] section (or `enabled = false`) keeps the v2 behaviour intact.
+# [server.relay]
+# enabled = true
+# Whitelist of allowed downstream exit addresses. ONLY literal IP:port entries; DNS resolution
+# is NOT performed in v3.1 (unparsable entries are logged at WARN and skipped). An empty list
+# turns this server into an OPEN relay accepting any downstream — dangerous; the runtime logs
+# a WARN on each accepted bridge.
+# allow_extend_to = [
+#   "198.51.100.5:443",   # the exit you operate
+#   "203.0.113.10:443",
+# ]