Restore transient connection boundary during connect handshake

[sanity]

Nacho highlighted in #2065 (comment) that PR 2065 merged the transient vs. accepted connection handling. In-transit sockets now look identical to established peers, so other operations could use them and they count against the steady connection pool.

To fix this we need to:

1. Reintroduce an explicit boundary between transient connections (only valid for their connect operation) and the steady-state pool.
2. Ensure transient sockets can be dropped without affecting ongoing ops, and that they never get exposed to other ops until the handshake completes.
3. Add regression coverage so future refactors don’t collapse the layers again.

This complements (but is distinct from) issue #2075, which focuses on the broader adapter refactor.

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-bug (95% confidence)
• P-high (80% confidence)
• E-medium (75% confidence)
• A-networking (95% confidence)

Reasoning: The report describes a regression introduced by a recent merge that collapsed the boundary between transient (handshake-only) and steady connections, causing in-transit sockets to be used as established peers and to count against the steady connection pool — this is a bug. It affects core connection handling (networking) and requires code changes plus regression tests, so it's moderate effort (E-medium) and high priority because connection-management regressions impact many peers. Adding developer/XP is relevant due to the need for tests/regression coverage.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.