feat(BackendTrafficPolicy): Support matching on response header for response override

[HusseinKabbout]

What this PR does / why we need it:

This PR was created because we would like to be able to generate something similar to the following envoy native config:

    envoy.filters.http.custom_response:
      "@type": type.googleapis.com/envoy.extensions.filters.http.custom_response.v3.CustomResponse
      custom_response_matcher:
        matcher_list:
          matchers:
          # 1) error + Content-Type: application/json  -> JSON error page
          - predicate:
              and_matcher:
                predicate:
                - single_predicate:
                    input: { typed_config: { "@type": type.googleapis.com/envoy.type.matcher.v3.HttpResponseStatusCodeClassMatchInput } }
                    value_match: { exact: "5xx" }
                - single_predicate:
                    input: { typed_config: { "@type": type.googleapis.com/envoy.type.matcher.v3.HttpResponseHeaderMatchInput, header_name: content-type } }
                    value_match: { prefix: "application/json" }   # also matches "application/json; charset=utf-8" 
            on_match:
              action:
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.http.custom_response.local_response_policy.v3.LocalResponsePolicy
                  status_code: 503
                  body: { filename: "/var/www/errors/5xx.json" }
                  response_headers_to_add: [ { header: { key: content-type, value: "application/json" } } ]
          # 2) error + Content-Type: text/html -> HTML error page 
          - predicate:
              and_matcher:
                predicate:
                - single_predicate:
                    input: { typed_config: { "@type": type.googleapis.com/envoy.type.matcher.v3.HttpResponseStatusCodeClassMatchInput } }
                    value_match: { exact: "5xx" }
                - single_predicate:
                    input: { typed_config: { "@type": type.googleapis.com/envoy.type.matcher.v3.HttpResponseHeaderMatchInput, header_name: content-type } }
                    value_match: { prefix: "text/html" }
            on_match:
              action:
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.http.custom_response.local_response_policy.v3.LocalResponsePolicy
                  status_code: 503
                  body: { filename: "/var/www/errors/5xx.html" }
                  response_headers_to_add: [ { header: { key: content-type, value: "text/html" } } ]
          # 3) catch-all (no/other Content-Type) -> TEXT error page  ← your "default to text" 
          - predicate:
              single_predicate:
                input: { typed_config: { "@type": type.googleapis.com/envoy.type.matcher.v3.HttpResponseStatusCodeClassMatchInput } }
                value_match: { exact: "5xx" }
            on_match:
              action:
                typed_config:
                  "@type": type.googleapis.com/envoy.extensions.http.custom_response.local_response_policy.v3.LocalResponsePolicy
                  status_code: 503
                  body: { filename: "/var/www/errors/5xx.txt" }
                  response_headers_to_add: [ { header: { key: content-type, value: "text/plain" } } ]

#8608 and #8856 were created in the past but they talk about supporting request header matching, which envoy does not support (yet ;D). What would be nice for now is support the response header matching, which envoy currently supports, in envoy gateway. In the future, request headers can be easily added since they would be very similar to the response header implementation.

The main use case for this is custom error pages which should return different response bodies based on the response content-type (see example from above).

---

PR Checklist

• Authorship & ownership: Coding agents / AI assistants are welcome, but I have reviewed every change, understand how and why it works, can explain and maintain it, and take full responsibility for this PR. I have not submitted generated output I do not understand.
• DCO: All commits are signed off (git commit -s). See DCO: Sign your work.
• API agreed first: If this PR contains API changes (changes under /api), the API was discussed and agreed before the implementation. The API change can be in a separate PR, or in the same PR, but the API must be agreed before implementation. N/A if this PR does not contain API changes.
• Required checks pass: make generate gen-check, make lint, and the unit-test/coverage build pass. (Flaky e2e failures are not considered breakages, but gen-check, lint, and coverage MUST pass.)
• Tests added/updated: New/changed code is covered by appropriate tests. N/A if this PR does not contain code changes.
• Docs: User-facing changes update the docs, either in this PR or a follow-up PR. N/A if this PR does not contain user-facing changes.
• Release notes: For any non-trivial change, added a release-note fragment under release-notes/current/<section>/<pr-number>-<slug>.md (see release-notes/current/README.md for sections and naming). N/A if this PR does not contain non-trivial changes.
• Generated files committed: Ran make gen-check and committed the result if API/helm charts/modules changed.
• Scope & compatibility: The PR is reasonably scoped (no unrelated changes) and preserves backward compatibility, or any breaking change is called out above and documented in release-notes/current/breaking_changes/.
• Codex review: Requested a Codex review and addressed all of its comments.
• Copilot review: Requested a Copilot review and addressed all of its comments.

[netlify]

✅ Deploy Preview for cerulean-figolla-1f9435 ready!

Name	Link
🔨 Latest commit	6daffcc
🔍 Latest deploy log	https://app.netlify.com/projects/cerulean-figolla-1f9435/deploys/6a58e6a7c1e8c70008f0a8d7
😎 Deploy Preview	https://deploy-preview-9354--cerulean-figolla-1f9435.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e2cc8fa982

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".