Proposal: experimental Events extension module (client and server) #2945

I'd like to add support for the Events extension (design sketch) under experimental/, next to tasks. I'm opening this before writing code because the extension isn't an accepted SEP yet, and I'd rather hear now whether that rules it out.

Why now

The conformance repo is adding an Events suite. Server scenarios are in modelcontextprotocol/conformance#521, and client scenarios are tracked in modelcontextprotocol/conformance#540. That repo runs its suites against this SDK and builds its everything-client on it. Without events support here, the client scenarios have to ship a hand-written JSON-RPC client as their passing example, which is how the MRTR scenario works today. An SDK module would replace that, and other SDKs would have a reference to compare against.

What it would cover

The extension has three delivery modes, and the module would cover all three on both sides.

On the client side, that means events/list; a poll loop that drains on hasMore and applies a 1000 ms floor; an events/stream call that skips the default request timeout and reconnects with its cursor when the stream goes quiet; webhook events/subscribe with a refresh loop scheduled from refreshBefore; cursor handling for truncated: true and cursor: null; and secret generation from a CSPRNG.

On the server side, it means the capability declaration, events/list, events/poll, events/stream with heartbeats, and webhook subscribe/unsubscribe with signed delivery. The five conformance server scenarios would grade this half.

Existing implementation

mcpkit (Go) has a server and a client for this extension, and its server was the main target while the modelcontextprotocol/conformance#521 suite was being built. Where the document is silent, the TypeScript module would follow mcpkit's behaviour, and the conformance suite would hold both to the same rows.

Questions/Considerations

1. Picking experimental/ as the location for this as the extension is not yet accepted. Any thoughts?