Connection lifecycle logs, long-wedge escalation, context on remaining warns

[petergaultney]

Three observability changes for diagnosing client-wedge incidents in pod logs:

1. Connection lifecycle log. handle_socket_inner previously logged nothing when a websocket ended - the close reason was computed but only fed to metrics. Now an info-level WebSocket disconnected reports doc_id, user, close_reason, and duration_secs, so wedged clients and reconnect loops are visible directly in the logs (a reconnect loop reads as rapid short-duration disconnects from one user). Connect is logged at debug to keep steady-state volume at one line per connection.

2. Long-wedge escalation. The full/recovered transition warns emit one line at the moment a channel fills - a client wedged for hours is silent after minute zero. While the channel stays full, re-warn every 5 minutes with the cumulative drop count and how long it has been full; the recovery line now also reports the total full duration.

3. Context on the remaining contextless warns. Error handling message and Received non-binary message get doc_id/user (the former fires per bad message, so it was the same defect class as the old backpressure warn); the subscription-lock and Subdocs/Event protocol warns in doc_connection.rs get user.

No behavior changes; cargo test passes. We are running the same changes in production.