fix: complete the cancellation chain across all binaries and crates

[Itsusinn]

Problem

Ctrl-C did not terminate tuic-server when running the quiche backend (backend.mode = "quiche"): the quiche inbound created its own standalone CancellationToken and its accept loop never checked any token, so the listen task and every live connection kept running until main's 10s drain timeout force-aborted them.

A follow-up audit of the cancellation mechanism across the whole workspace found several more components that ignored the cancel token, leaked detached tasks past shutdown, or risked pinning a runtime worker.

Changes

tuic-server (quiche backend)

• TuicheInboundBuilder::cancel_token(): the accept loop now select!s the token; per-connection tokens are children of it, so one cancel() stops accepting and closes every live connection.
• create_quiche_inbound wires ctx.cancel.child_token() into the builder, mirroring the quinn backend.
• Connection handlers are tracked in a TaskTracker and awaited after the accept loop exits, so CONNECTION_CLOSE frames flush before the runtime drops.
• wind-quic: the accept-forwarding task in bind_server exits once all QuicheAcceptors are dropped, releasing the listener socket/router.

tuic-server (quinn backend)

• After the listen loop exits: endpoint.close() + wait_idle() so queued close frames flush; previously peers only learned about the shutdown via idle timeout.
• Connection handlers are spawned into the shared ctx.tasks TaskTracker (previously created but unused).
• The CertResolver file watcher takes a cancel token instead of looping forever.

tuic-client

• Previously had no shutdown path at all — ctrl-c hard-killed the process and the server only noticed via idle timeout. Now: run_with_cancel(), ctrl-c → cancel → 10s drain in main (same structure as tuic-server), token-aware SOCKS5 accept loop and TCP/UDP forwarders, per-session tasks tracked in TaskTrackers.
• wind-tuic (quinn outbound): on cancellation the heartbeat poll closes the QUIC connection ("client shutdown") so the server reaps it immediately.

wind / wind-socks

• Per-connection SOCKS tasks get a child token and are tracked; the detached UDP association task is cancel-guarded; listen waits for in-flight sessions on shutdown.

wind-naive

• Stop join()ing the bridge I/O thread from async — a parked blocking naive.read() would pin a tokio worker indefinitely. Drop the handle instead (same strategy as the UoT relay path).

Verification

Tested on Windows by sending real CTRL_C_EVENTs (via AttachConsole + GenerateConsoleCtrlEvent):

Scenario	Before	After
tuic-server quinn	exits promptly	exits < 1s, close frames flushed
tuic-server quiche	hangs 10s, then force-aborted	exits < 1s with graceful shutdown logs
tuic-client (relaying live traffic)	hard kill, server waits idle timeout	exits < 1s; server logs Connection closed immediately

cargo build / cargo clippy clean with the quiche feature; 164 unit tests pass across the modified crates.

🤖 Generated with Claude Code