Demote noisy "Client network socket disconnected before TLS" log during initial replication setup

The error `Client network socket disconnected before secure TLS connection was established` shows up in production logs and is confusing for first-time users. Per Devin's analysis, the error originates from initial replication setup — peers are reachable but the TLS handshake is racing against connection lifecycle, producing a transient error that's expected during startup but logged at error level.

## Ask

Detect the "initial replication setup" context and either:
- Downgrade the log level to `debug` / `trace` for these transient disconnect errors, OR
- Suppress and retry silently for a short window after startup, falling through to the existing error log if the condition persists.

## Why this matters

First-time-user impression: the log shows ERROR-level entries during a normal startup, suggesting Harper isn't working when it actually is. Documented as a known issue would be acceptable too, but downgrading the log is cheaper.

## Implementation notes

- Devin noted "would need some core changes around the log" — the log emission point is likely in the WS / TLS handshake path. Wrap the disconnect-before-TLS-completed case with a check for "is this within the initial replication setup window?" and demote.

## Acceptance criteria

- Initial replication TLS-handshake races don't produce ERROR-level logs.
- Genuine TLS connectivity failures (e.g. a peer that's actually unreachable) still log at ERROR.

---

🤖 Filed by Claude on behalf of Kris.