Description:

When two BackendTLSPolicy resources target the same backend — one with targetRefs[].sectionName set, one without — the unsectioned (wildcard) policy unconditionally shadows the sectioned one if it appears earlier in the input list (which it does whenever it's older, since policies are sorted by CreationTimestamp ASC).

I think this is incorrect according to the gateway API spec for BackendTLSPolicy where it only states precedence checks should be done between matching target and sectionName

When more than one BackendTLSPolicy selects the same target and
sectionName, implementations MUST determine precedence using the
following criteria, continuing on ties:

• The older policy by creation timestamp takes precedence

ref https://gateway-api.sigs.k8s.io/reference/api-spec/main/spec/#backendtlspolicy

cc @nareddyt

Repro steps:

See #9034 for UT repro

Plain english explanation:

1. create ServiceImport with spec.ports: [{name: http, port: 8000}, {name: https, port: 8443}].
2. create BackendTLSPolicy A targeting that ServiceImport, no sectionName, created first.
3. create BackendTLSPolicy B targeting the same ServiceImport with sectionName: https. created after A.
4. create HTTPRoute whose backendRef points at the ServiceImport with port: 8443.

Expected: HTTPS upstream uses B's validation config; B gets ancestor status with Accepted: True.

Actual: HTTPS upstream uses A's validation config; B's status stays empty.

Environment:

• Envoy Gateway: main (also reproduced on v1.6.4).
• Gateway API CRDs: v1.2.x.

Logs:

N/A — the bug manifests as silent omission. EG emits no log lines for the shadowed policy because the translator never enters any code path that references it.