[Feature] SessionHooks should support multiple handlers per hook slot

首先定位 SessionHooks 和现有的 hook 调用行为，尤其是 OnPostToolUse 和 OnPreToolUse。将当前的 single-delegate 和 multicast-delegate 行为与提议的 UsePreToolUse 和 UsePostToolUse pipeline 进行比较。完成的标准是：处理程序可以按明确的顺序组合，同时检查、修改、短路或转发 hook 执行，而不会在无提示的情况下覆盖它。

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.