fix(gatewayapi): isolate nested wildcard listeners on a shared port

[omkar619-dev]

What this PR does / why we need it:

A route with a concrete hostname attaches to a less specific wildcard listener even when a nested wildcard listener on the same port already owns that hostname, so both listeners serve the route.

The filter at the end of computeHosts removed a sibling listener's hostname from the route's matched set as a literal string:
hostnamesSet.Delete(string(*listener.Hostname))

That only deletes something when the set happens to hold that exact string. The match phase resolves the set to whatever the route asked for, so with a sibling *.dev.example.com and a route hostname test.dev.example.com the set holds the concrete name, the delete matches nothing, and the apex *.example.com listener keeps a host it does not own. That is at odds with the function's own doc comment, which says it returns hostnames "that don't intersect with other listener hostnames".

This replaces the literal delete with a specificity comparison: a sibling removes any matched hostname it matches at least as specifically as the listener being computed. Specificity ranks an exact hostname above any wildcard, a longer wildcard suffix above a shorter one, and an empty listener hostname - which matches everything - below both.

Behaviour for existing configurations is unchanged: an exact sibling outranks any wildcard and still deletes, exactly as the literal delete did.

Notes for reviewers:

• The comparison is >=, not >. Equal specificity means an identical hostname, and only the loser of that conflict reaches this loop with the winner as its sibling, because the hostnameConflictLoser guard skips the other direction - so the two can never delete each other's hosts. A strict > regresses TestComputeHostsConflictOwnership.
• hostnameMatches handles string equality itself, because wildcardHostnameMatchesHostname returns false for two identical wildcards: its remaining is empty and it requires len(remaining) > 0.
• The empty listener hostname is ranked lowest explicitly. A first attempt let it fall through to the exact-hostname branch, since it has no "*" prefix, which made the most permissive listener rank as the most specific. The existing gateway-http-listener-with-hostname-intersection fixture caught that.
• No golden files changed. A filter that deletes more could easily have shifted testdata output, and none of it moved.

The failure is invisible in status: every listener stays Programmed: True, the correct certificate is served on the HTTPS variant, and nothing is logged though, so the only reliable detection is comparing each listener's rds.route_config_name against the names actually present in RoutesConfigDump.

It was reported by @steache, who confirmed across five clusters that the discriminator is the route hostname rather than the Envoy Gateway version; and also @TheisFerre confirmed the guard added in #9768 is a no-op for this shape.

Which issue(s) this PR fixes:

Fixes #9895

[netlify]

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

Name	Link
🔨 Latest commit	1eb791a
🔍 Latest deploy log	https://app.netlify.com/projects/cerulean-figolla-1f9435/deploys/6a9a65c248e4e700089ea2af
😎 Deploy Preview	https://deploy-preview-9947--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: 64380e2b81

ℹ️ 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".