IPC v1: resolve contradictory unknown-notification semantics #425

Context

The notification evolution rules on feat/ipc-v1 at ce29ab8 / #362 currently point in different directions.

Contradictions

In docs/src/content/docs/reference/ipc-wire.md:

• the JSON-RPC profile says unknown notifications are ignored;
• the forward-compatibility section says an unknown notification method remains a protocol violation;
• the same section says request and notification objects reject unknown members.

The artifacts differ too:

• schema/ipc/v1/common.schema.json constrains method to rpc.cancel but sets additionalProperties: true on NotificationEnvelope;
• secretspec-ipc/src/jsonrpc.rs::Notification uses #[serde(deny_unknown_fields)];
• secretspec-ipc/src/client.rs and server.rs effectively ignore unknown notification methods after envelope parsing.

This leaves independent implementations unable to know whether an unknown notification should be ignored, produce diagnostics, or terminate the session.

Suggested resolution

Prefer normal JSON-RPC notification semantics:

1. Keep the notification envelope structurally strict (jsonrpc, method, params; no unknown top-level members).
2. Ignore an unknown notification method because it has no response channel.
3. Continue ignoring unknown/completed cancellation IDs and malformed rpc.cancel parameters as already documented.
4. Remove the statement that unknown notification methods are protocol-fatal, or explicitly choose the opposite behavior and make code/schema agree.
5. Explain how future notification methods are capability-gated even when older receivers ignore them.

Deterministic coverage

Add conformance cases for:

• unknown notification method;
• unknown top-level notification member;
• malformed rpc.cancel params;
• cancellation for unknown and terminal IDs;
• a valid request after each ignored notification case to prove whether the session remains usable.