Generalize EgressPolicy header modification with literal and secret-backed values

[EItanya]

The current inject_static_headers API requires a credential reference for every header. Replace this credential-specific model with a generic request header modifier supporting set, add, and remove, with secrets as one possible value source.

effects:
  requestHeaderModifier:
    set:
      - name: X-Client-Version
        value: "2026-09"
      - name: Authorization
        secret:
          uri: substrate-secret://example.com/provider/api-token
          prefix: "Bearer "
    add:
      - name: X-Client-Tag
        value: substrate
    remove:
      - X-Internal-Debug

Proposed types:

message RequestHeaderModifier {
  repeated HeaderValue set = 1;
  repeated HeaderValue add = 2;
  repeated string remove = 3;
}

message HeaderValue {
  string name = 1;

  oneof source {
    string value = 2;
    SecretHeaderValue secret = 3;
  }
}

message SecretHeaderValue {
  string uri = 1;
  string prefix = 2;
}

Expose RequestHeaderModifier through EgressRuleEffects.request_header_modifier. This follows Gateway API’s RequestHeaderModifier operation model while extending header values to support secret references.

Behavior

• set replaces all existing values for the named header.
• add appends a value while preserving existing values.
• remove deletes all values for the named header; an absent header is a no-op.
• Header names are case-insensitive. Each header may appear only once across the operations, making operation order irrelevant.
• Values are either literals or secret references. Secret-backed values are constructed as prefix + resolved secret, preserving support for Bearer <token> without a template language.
• The modifier applies only to requests authorized by the first matching hostname rule.

Related: #1317 — Add extension points to egress policy.

[LiorLieberman]

Responded in #1751 but leaving here as well.

While its true that we may eventually need to support a full blown model of header operations, I am worried we are trying to port more Gateway API features in a rush and bringing unnecessary complexity at the current stage of the project.

For this one specifically we discussed and decided we dont do that for GA

IMP we should revisit based on feedback