[Feature] SessionHooks should support multiple handlers per hook slot

Start by locating SessionHooks and the existing hook invocation behavior, especially OnPostToolUse and OnPreToolUse. Compare the current single-delegate and multicast-delegate behavior with the proposed UsePreToolUse and UsePostToolUse pipeline. Done means handlers can compose in explicit order while inspecting, modifying, short-circuiting, or forwarding hook execution without silent clobbering.

At least in C#, SessionHooks properties (OnPostToolUse, OnPreToolUse, etc.) are single-assignment delegates. This makes it easy to accidentally clobber a previously-registered handler with =, and there is no SDK-level way to compose multiple handlers.

Why this matters for library authors

We are building a library on top of the SDK. Our framework needs to register its own hooks (for example, observing update_todo calls in a post-tool-use hook to persist state). But we also need to leave hook slots open for our downstream consumers to register their own hooks.

Today there is no safe way to do this. We can build our own closure-chaining helper (capture the existing delegate and wrap it), but since SessionHooks properties are public settable, any downstream consumer doing config.Hooks.OnPostToolUse = myHandler silently clobbers our framework hook. We cannot prevent that as a library because we do not control the downstream code.

Multicast delegates (+=) do not appear to work either, because await hooks.OnPostToolUse(...) only awaits the last delegate in the invocation list.

What would help

A middleware-style pipeline where each handler receives a next delegate and decides whether to call it, short-circuit, or modify the input/output. This gives callers full control over composition without the SDK needing different resolution rules for different hook types:

hooks.UsePreToolUse(async (input, invocation, next) => {
    // inspect, modify input, or short-circuit
    return await next(input, invocation);
});

hooks.UsePostToolUse(async (input, invocation, next) => {
    var result = await next(input, invocation);
    // observe, modify result, or replace it
    return result;
});

This is the same pattern as ASP.NET Core middleware and Akka message pipelines. It is simple to reason about, order is explicit, and each handler can decide independently whether to pass through or stop the chain. No special-case semantics per hook type needed.

Workaround

We worked around this by moving our observer to session.On() events instead of hooks, which works for our case but is not a general solution for hooks that need to mutate tool behavior.