fix(transport): correctness pass on the notification link, RPC batch and plugin notifications

[matej21]

Six independent corrections to the transport layer, one per commit.

Drop the dead request/response protocol layer. method(), MethodDef, the caller/handler types built on them and the method-only half of Protocol had no callers: the router and connection base are notification-only, both SDK adapters serialise raw frames, and request/response is carried by HTTP /rpc. Removed together with its re-exports from every entry point; the notification protocol API the router and Connection.notify use is untouched. SafeParseResult becomes a public export, since Protocol.validateInput returns it by name.

Let the agent notice a heartbeat that is never answered. The 10s probe was one-directional: the client sent it and drew no conclusion from silence, so a dead link looked healthy from the agent's side. The probe and its answer are now complete frames that each side reads before acting on, ServerAdapter answers one, and three unanswered probes in a row force a reconnect.

Scope, plainly: detection arms only against a peer that answers the probe, and re-arms per connection. The only answering implementation in this repository is ServerAdapter, which runs in standalone mode — where ClientAdapter is not used. So against a host that does not yet answer, behaviour is unchanged by design: the client keeps its link rather than tearing it down. The answering half for such hosts is a separate change, not in this PR.

Settle every item in an RPC batch. The loop broke on the first non-ok item and still returned HTTP 200, so results could be shorter than batch with nothing in the body to say so — a caller could not tell a completed batch from a truncated one. Every item now runs and gets its own envelope, so results.length always matches batch.length. No caller depends on the fail-fast for results.length — but the side-effect ordering does change, and one caller is affected. RpcClient.batch still collapses to the first failing envelope, while items after it have now executed and committed. session-store.ts batches user-chat.answerQuestion for every pending question: if the first fails, the rest are now submitted and succeed, the client still returns Err, the UI marks all of them errored, and a retry re-submits answers that already landed. answerQuestion was not idempotent — its handler minted a fresh messageId and its reducer appends unconditionally to pendingInbound, so the agent read the answer twice. This PR now drops an answer to a question that already has one, in the handler. The guard is deliberately not in the reducer: a recorded event still replays exactly as written (replays each immutable answer value pins that a second answer overwrites the first on replay), so only new duplicates are prevented.

That bounds the damage but does not remove the cause: RpcClient.batch still tells the caller nothing about which items succeeded. Surfacing per-item results is a required follow-up before the client-side batch is relied on for anything with side effects. Because running every item makes the batch length the amount of dispatch one request buys on a client-facing endpoint, the length is now capped at 100 (batch_too_large, HTTP 400).

Enforce declared notification schemas. .notification(name, { schema }) described a contract nothing checked. The plugin builder now validates every ctx.notify against the declared schema and drops what does not match, logging the plugin and the type. This surfaced the services plugin broadcasting serviceStatus without declaring it; the declaration is added here. The guard sits in the builder rather than in the session so agent-side hook contexts are covered by the same check — seven context kinds share the seam; method handlers and session hooks are covered by test.

Document two invariants (comments only, no behaviour change): _caller is read straight off the request body with no shape check, so anything holding the bearer token can set it — it is a hint about the caller, not proof of one, and validating it is a follow-up; and fetch-guard validates a hostname but hands the name to fetch, so it filters where a request may point rather than guaranteeing where the connection lands.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CbVWntVv8xSdtn6DC6ZApM