Introduce InterceptorOverrides in the chain execution model

[jeongukjae]

Introduce InterceptorOverrides in the chain execution model to separate interceptor capability (server-declared) from execution policy (invoker-declared).

Why

The SEP currently locks all execution policy (failOpen, priorityHint, mode) into the interceptor's own definition. This means:

• If an interceptor declares failOpen: false but is known to be flaky in your deployment, you can't make it fail-open without changing the server
• If you want the same interceptor in audit mode in staging but active in production, there's no mechanism
• If you want to restrict an interceptor to only tools/call even though it declares support for tools/call + llm/completion, you have to invoke it and hope the chain filters correctly
• Priority is fixed by the author, so platform teams can't reorder interceptors for their deployment topology

In short: the chain interface had no policy layer, making it impractical for real-world multi-environment deployments.

Changes

1. New "Capability vs Policy" subsection explaining the two-layer model
2. New InterceptorOverrides interface (failOpen, priorityHint, mode, timeoutMs, hooks)
3. ChainEntry gains overrides?: InterceptorOverrides
4. resolvePriority() updated to check overrides first
5. Orchestration steps updated — new step 2 "Resolve Policy"
6. New example showing overrides in action (priority override, mode promotion, fail-open for fragile interceptor)
7. New rationale entry (Design Decision 4) explaining why both layers exist

[PederHP]

LGTM