Addresses the third item of #15 ("Chain orchestrator only supports one MCP server").

Stacked on #17 — this PR targets that branch because it builds on the per-phase PriorityHint resolution introduced there. After #17 merges, the base will be switched to main (or it can be retargeted now and rebased).

What changed

The SEP's chain execution pattern requires: discover via interceptors/list on one or more servers → merge & sort all interceptors into a single chain by priorityHint (ascending, alphabetical tie-break) → invoke each interceptor on the server that hosts it (mutations sequential with payload chaining, validations parallel) → aggregate one result. The SDK previously ran each client's entire chain sequentially, so a -1000 mutation on server 2 ran after a +1000 mutation on server 1, and each server's validations only saw its own server's mutations.

• Orchestrator (InterceptorChainOrchestrator, internal): now operates on chain entries — descriptor + invoker routing to its host — mirroring the SEP's ChainEntry, with one global sort across all filtered entries. The stable sort preserves caller-supplied server order for exact ties.
• New public API (InterceptorChain / InterceptorChainEntry): DiscoverAsync lists from every server in parallel (fail-closed: any list failure throws rather than silently dropping a server's interceptors), instance ExecuteAsync runs prebuilt entries (a future caching seam), and a one-shot static ExecuteAsync(servers, params) does discover + execute.
• InterceptorChainRunner (used by the gateway and InterceptingMcpClient): one merged chain instead of the per-client sequential loop. The single-client client.ExecuteChainAsync(...) extension keeps its signature and delegates to the same path (still 1 list + N invokes).
• Duplicate interceptor names across servers are not deduplicated — each entry invokes on its own host (results may share an InterceptorName; documented).

Behavior changes for multi-client gateways

• Interceptors from all servers form one globally-ordered chain (previously server 1's full chain ran before server 2's).
• Validations from all servers run as one parallel batch against the payload after all mutations.
• Sinks run once per phase for the merged chain (previously once per client).
• TimeoutMs bounds the whole merged chain, not each per-client sub-chain.
• Any server's interceptors/list failure fails the chain up-front (fail-closed).
• Cost per phase: M parallel interceptors/list calls + N interceptor/invoke calls.

Testing

dotnet test from csharp/sdk/: 97 passing (was 87 after #17). New coverage:

• Orchestrator: global priority ordering across servers, alphabetical tie-break across servers, payload chaining across servers in one mutation pass, all-server validations seeing the post-mutation payload, duplicate names invoking once per host.
• InterceptorChainTests (real in-memory servers): discovery merge with server attribution, merged execution order, fail-closed discovery, single-client path equivalence.
• Gateway: two interceptor servers where the second hosts the lower-priority mutation — the backend receives the globally-ordered payload (fails under the old sequential runner).

Closes #15.

🤖 Generated with Claude Code