feat: fast CONNECT recovery for NATed peers via TTL=0 gateway fallback

[sanity]

Problem

After suspend/resume (or any isolation event), a NATed peer tries to reconnect via initial_join_procedure. The gateway routes CONNECT requests to ring peers, but if those peers are also behind NAT, the joiner can't reach them (NAT-to-NAT hole punching fails). Each failed attempt takes ~10s (transport handshake timeout) before the bloom filter is updated. With many NATed peers in the gateway's ring, reconnection can take many minutes.

Observed on technic: Zero ring connections after suspend, stuck in isolation loop with NAT traversal failing to all acceptor peers routed by the gateway.

Approach

When the joiner has zero ring connections, include one CONNECT request with TTL=0 alongside normal requests. TTL=0 forces the gateway to accept directly (no forwarding to potentially NATed acceptors). Since the joiner already has a transient connection to the gateway, no NAT traversal is needed.

Why TTL=0 works

1. Gateway receives ConnectRequest { ttl: 0 }
2. can_forward = self.forwarded_to.is_none() && self.request.ttl > 0 → false
3. is_terminus = true → gateway checks should_accept() → accepts (has capacity)
4. Sends ConnectResponse with gateway as acceptor
5. Joiner calls ConnectPeer { is_gw: false } → promotes existing transient connection to ring
6. No NAT traversal needed — connection already exists

Key design decisions

• TTL=0 is additive: One TTL=0 request + remaining normal-TTL requests run in parallel. If gateway rejects (at max_connections), normal routing still works.
• Only when open_conns == 0: Normal topology optimization continues for non-isolated peers.
• No protocol changes: TTL=0 is a valid value that the existing state machine handles correctly.
• No duplicate connection risk: should_accept() and handle_connect_peer() have idempotent guards.

Changes

• join_ring_request(): Added ttl_override: Option<u8> parameter to allow callers to override the default TTL
• initial_join_procedure(): When open_conns == 0, first gateway request uses TTL=0 for fast direct bootstrap
• handle_aborted_op(): Updated two call sites to pass None (no TTL override)

Testing

• cargo fmt && cargo clippy --all-targets — clean
• All 1371 tests pass (cargo test -p freenet)
• test_multiple_clients_subscription fails on unmodified main too (pre-existing, unrelated)

[AI-assisted - Claude]

[sanity]

Superseded by PR #3015 (merged Feb 16) which solved the root cause with TTL-aware reservation cleanup. The TTL=0 gateway workaround is no longer needed. [AI-assisted - Claude]