Add error flow support in the policy engine

Description

Currently, when a policy in the main chain short-circuits with a direct response to the downstream (e.g., a guardrails policy blocking a request due to a violation), the policy chain stops immediately and no further policies execute. There is no mechanism for other policies to observe, enrich, or act on that error response before it is sent to the client.

This limits composability for common API gateway use cases:

• Error enrichment — a policy that adds context-specific detail or a standardized error format to the body returned by a guardrail or rate-limiter violation.
• Observability — a policy that emits a trace or metric to an OTel collector when a guardrail fires, without needing to bake that logic into the guardrail policy itself.
• Audit / alerting — a policy that records or forwards the failed request details to an external system.

The proposal is to introduce an error flow: a second, separately-configured policy chain that executes after the main chain short-circuits. Error flow policies receive the original request context and the details of the triggering error (status code, body, headers, triggering policy name), and can modify the final response or perform side effects before it is returned to the downstream.

This is analogous to fault sequences in WSO2 ESB/MI, error handlers in MuleSoft, and onException clauses in Apache Camel — a well-established abstraction in API gateway/integration products.

Scope

• SDK: new error flow policy interface and error context type
• Policy engine (chain executor): execute the error chain after a main-chain short-circuit
• Gateway controller: resolve and serve the error policy chain as part of the xDS snapshot
• Gateway builder: compile error flow policies into the policy-engine binary
• API policy YAML: new errorPolicies section alongside the existing policies section

Version

No response

Related Issue

No response

Start by reading the SDK, policy engine chain executor, gateway controller, gateway builder, and API policy YAML areas named in the scope. Trace how the existing main policy chain is configured, resolved, compiled, and executed. Done means an error policy chain can observe a short-circuit, use its error context, and modify or finalize the response across all listed components.