daemon: no handshake timeout / no max_connections cap on the collab TCP accept loop

[cuttlefisch]

Source: hub-model shared-KB readiness review.

What

daemon/src/main.rs's TCP accept loop and shared/mcp/src/auth.rs's
server_handshake implementations have no tokio::time::timeout wrapper around the
handshake read, and no cap on concurrent accepted-but-unauthenticated connections.
daemon/src/config.rs's resource ceilings (max_documents, max_update_size_bytes,
max_document_size_bytes) bound per-document/per-message size, but nothing bounds
total connection count or per-IP rate.

Why it matters

A client that opens the TCP/TLS connection and never sends its hello line (deliberately,
or just a flaky network dropping the line) ties up a task+socket indefinitely. Combined
with no max_connections, this is the one genuinely open-ended resource in the whole
hub model — a real risk for any demo/deployment reachable beyond localhost (even just a
shared LAN), not requiring anything sophisticated to trigger.

What's needed

1. Wrap the per-connection handshake read in a bounded tokio::time::timeout (a few
   seconds is plenty — real clients complete the handshake near-instantly).
2. Add a max_connections (or per-IP) config knob (principle feat: Phase 4a M5 — async LSP AI tools #7 — no hardcoding) with
   a sane default, enforced in the accept loop.
3. Adversarial test: an accepted-but-silent connection must be dropped within the
   timeout, and a connection-count cap must actually reject the (N+1)th unauthenticated
   client (principle feat: editor polish, version bump & new features (v0.3.0) #14 — the attacker's test, not just the happy path).

Size: S-M.

[cuttlefisch]

Fixed in-tree — verified during the repo-wide audit (2026-08).

Evidence: daemon/src/config.rs CollabConfig::max_connections (default 256), enforced in main.rs via conn_limit::ConnLimiter with an explicit #342 comment; TLS and plaintext handshake deadlines both present

Closing as part of a sweep of open issues describing problems that are already resolved. If this was closed in error, the evidence above is the thing to check first.