Public inbound-processing completion seam for reusable bounded admission #3020

Problem

A transport can bound concurrently admitted requests, but its public onmessage callback returns void. It cannot observe when the corresponding inbound SDK handler has finished result validation/encoding, response sending and internal cleanup.

Releasing admission on transport.send is premature: Protocol._onrequest deletes its abort-controller entry in a later finally. Cancellation can suppress sending entirely while an asynchronous handler is still running. Keeping all request IDs and reservations for the connection lifetime avoids premature reuse, but prevents a bounded, indefinitely usable connection.

Reproduction

Use a Server with a handler held by a deferred promise and a transport whose send is separately deferred. Dispatch a request, cancel it while the handler is held, and observe that no response is sent. The handler can still be running after cancellation. For a successful request, hold send: neither handler return nor entry into send establishes final processing completion.

This applies to ordinary SDK resource accounting, independently of SSH or application-specific authorization. It does not propose any wire-protocol change or claim that local completion proves remote-effect rollback.

Proposed public seam

An optional transport-side per-message processing-completion callback, propagated through serveStdio opening/queue routing and invoked once after actual SDK processing and owned response sends settle. A request's callback must run after its handler controller is removed, including cancellation, rejected handlers, invalid envelopes, unknown methods and failed response sends. Notifications need their own actual handler completion. Connection close alone must not complete unfinished handlers.

The callback is local metadata, never a JSON-RPC field. Applications keep admission policy and physical downstream-operation accounting; the SDK retains negotiation, dispatch, framing and cleanup. Existing callers without the callback retain their behavior.

I would like to contribute a focused implementation and adversarial lifecycle tests. Would this transport-side completion seam fit the SDK's public API direction?