fix(daemon): daemon closes the connection mid-request in multi_connection_test

[ScriptedAlchemy]

storage_suite multi_connection_test (2 tests) fails on Test Linux at harness.rs:337 with daemon closed the connection after the request was sent but before returning a matching response, and at fail_closed.rs:101. The tests spawn a real daemon which exits mid-request; the root cause is on the daemon side and was not diagnosed (needs the daemon stderr from a local repro).

Found during the 2026-09-04 CI sweep; reported by the daemon_suite lane. Possibly the same family as #881 (HostAdmissionTestRuntimeV1::project holding the project session store's single-writer authority across processes).

[ScriptedAlchemy]

Split (2026-09-05, cc-5825): split_brain_is_rejected_and_unavailable_daemon_fails_closed_until_restart is not a daemon bug: doctor refuses to open SQLite, reports "Health remains unknown" and changes nothing, but grades it as a warning and exits 0. Fix: crates/tracedecay/src/doctor.rs:433 dc.warn(...) → dc.fail(...) for "Canonical Doctor report unavailable from the sole daemon owner" (doctor_result already errors when dc.issues > 0). twelve_mcp_cli_and_hook_clients_share_one_daemon_profile_store_owner still needs daemon stderr captured by the harness to localize the mid-request close.

[ScriptedAlchemy]

Doctor half fixed at d6d3f17 (split_brain_is_rejected_and_unavailable_daemon_fails_closed_until_restart passes; the unavailable canonical report now fails the doctor exit with a pinned test). The harness now quotes the daemon stderr tail on every client-side failure (45c5993), which exposed the cause of twelve_mcp_cli_and_hook_clients_share_one_daemon_profile_store_owner:

event=daemon_client outcome=error error="config error: rmcp server initialization failed:
  expect initialized request, but received: Some(Request(JsonRpcRequest { id: Number(1),
  request: CustomRequest(CustomRequest { method: "initialize", params: Some(Object {}) }) }))"

The harness sends initialize with params: {}; rmcp cannot deserialize it into InitializeRequest, demotes it to CustomRequest, and the routed connection's initialization state machine tears the connection down instead of writing a typed JSON-RPC error on that id. Fix in crates/tracedecay/src/mcp/server/connection.rs (serve_server initialization path): answer a malformed or unrecognized initialize with a typed error frame before closing, as the daemon already does for unparseable handshakes and rejected auth prefaces. The harness was deliberately not changed to send valid params, since that would hide the teardown this issue is about.

[ScriptedAlchemy]

rmcp half fixed at f2812d18c (crates/tracedecay/src/mcp/server/rmcp.rs, +179).

Root cause, pinned to the dependency. The lock resolves rmcp to 3.1.1. In rmcp-3.1.1/src/service/server.rs, serve_server_with_ct_inner breaks out of its pre-initialize loop with the first non-ping request, then:

let initialize_request = match request {
    ClientRequest::InitializeRequest(request) => request,
    mut request => {
        if !request.get_meta().missing_required_keys(&ProtocolVersion::V_2026_07_28).is_empty() {
            return Err(ServerInitializeError::ExpectedInitializeRequest(Some(
                ClientJsonRpcMessage::request(request, id),
            )));   // <- nothing is written to the transport
        }
        ...

initialize with params: {} does not deserialize into InitializeRequestParams, so it arrives as CustomRequest { method: "initialize", .. }, and a first request with no _meta has empty required keys, so it takes that early return Err. No frame reaches the wire. daemon/connection_serving.rs:162 turns it into TraceDecayError::Config { "rmcp server initialization failed: ..." } and the socket drops — which the client reports as "the daemon closed the connection after the request was sent but before returning a matching response". (rmcp 3.1.4 added a missing_request_metadata_error frame on that path upstream; we are not on it, and this fix does not depend on bumping.)

Fix. RmcpConnectionAdapter::serve now wraps the transport in a GuardedHandshakeTransport that, before the handshake settles, answers a malformed initialize with a typed -32602 invalid-params error on that request's own id and then skips the message, so the connection is still able to accept a corrected initialize. The guard goes inert on the first non-ping request it forwards. It is installed inside serve rather than at the call sites because rmcp moves the transport into its initialization state machine, so no caller can reach the wire once that machine fails.

The daemon transport's observe_incoming_message already registered the request id in active_requests before the message reached the guard, so take_response_write finds the entry, the refusal is actually written, and the active-request registry settles exactly as for any other answer — the half-close/EOF path stays consistent.

Test added (same file, mod tests): malformed_initialize_is_refused_typed_and_a_corrected_handshake_still_serves drives a real RmcpConnectionAdapter over a duplex, writes {"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}, asserts a typed frame with id: 1 and error.code: -32602, then writes a well-formed initialize on id: 2 and asserts the result.serverInfo comes back on the same connection. It also asserts serve itself no longer fails initialization.

Verification status. rustfmt --edition 2024 --check is clean on the file. The cargo runs are still outstanding: the cargo-hauler daemon has been in a start/shutdown crash loop for the last hour (daemon.log shows ~10 listen/shutdown pairs inside 60s plus Cannot find module '/fast/cache/cargo-hauler/scripts/hauler.mjs'), and every ticket submitted from this lane (cc-5928, cc-6028, cc-6088, cc-6099, cc-6111, cc-6121, cc-6125, cc-6127, cc-6128) ended killed — daemon shutdown or daemon unreachable. Still needed once the broker is stable:

• cargo test -p tracedecay --lib mcp::server::rmcp::
• cargo clippy -p tracedecay --all-targets -- -D warnings

Leaving this open: the daemon-side twelve_mcp_cli_and_hook_clients_share_one_daemon_profile_store_owner end-to-end assertion should be re-run against a daemon built from this commit to confirm the harness now gets its typed refusal instead of a closed socket.

[ScriptedAlchemy]

Fixed on codex/tracedecay-total-redesign-plan-reopened (PR #707): f2812d18c answers a malformed initialize with a typed -32602 refusal on the rmcp path and keeps the connection usable for a corrected handshake (rmcp 3.1.1 dropped the socket without writing a frame); 89cdfe4ed/69569086b make doctor treat a reachable daemon whose project telemetry is still warming as a warning with unknown health (fail-closed stays for an unreachable owner, which d6d3f17 introduced); 59d8aba sends a conforming initialize from the multi-connection harness; 3a2b142 repairs the harness's remaining fixture defects. Evidence: mcp::server::rmcp tests 8 passed (malformed_initialize_is_refused_typed_and_a_corrected_handshake_still_serves); storage_suite 113 passed including split_brain_is_rejected_and_unavailable_daemon_fails_closed_until_restart and twelve_mcp_cli_and_hook_clients_share_one_daemon_profile_store_owner; Hermes stock integration green on CI since 59d8aba.