IPC v1: specify and test connection closure after initialization-state violations

[mamoreau-devolutions]

Context

An independent provider implementation review found that correct pre-negotiation termination behavior had to be inferred from the Rust server rather than from an explicit state-machine rule.

Problem

docs/src/content/docs/reference/ipc-wire.md says the receiver rejects:

• an application request before successful initialization;
• a second rpc.initialize request;
• unsupported initialization protocol/version combinations.

It does not consistently state whether the receiver sends one terminal error and keeps the connection open, or sends the error and closes it.

secretspec-ipc/src/server.rs currently sends invalid_request and closes for a pre-initialization application request or second initialize. During an active initialize, another inbound request also cancels initialization, receives invalid_request, and ends the session. This is security-relevant state-machine behavior and independent endpoints should not have to reverse-engineer it.

The checked-in conformance/ipc/cases/wire-rejections.json does not cover these valid-JSON state violations.

Suggested normative rule

Define a failed initialization state explicitly. For example:

• before readiness, only the initial rpc.initialize, its cancellation, and responses to callbacks raised by that initialize are valid;
• any other request receives at most one value-free invalid_request response and the connection then closes;
• unsupported protocol/version returns unsupported_version and closes;
• a malformed/invalid initialize returns the appropriate error and closes;
• a second initialize after readiness returns invalid_request and closes;
• no application request is processed after any failed initialization.

Please also specify whether the client must close immediately when it receives an unmatched response before initialization.

Deterministic coverage

Add black-box cases for:

• application request before initialize;
• response before initialize;
• second initialize while the first is active;
• second initialize after readiness;
• unsupported protocol/version;
• invalid initialization params;
• proof that the endpoint closes and performs cleanup after each case.