feat: set IngressRule.Tag from traffic target name

[kahirokunn]

Populate the new Tag field when building IngressRules so that downstream ingress controllers can trace generated resources back to their originating traffic tag.

Proposed Changes

When a Knative Service has traffic tags, tagged HTTPRoutes are generated but have no metadata indicating which tag they belong to. This makes it difficult for external tools to identify the traffic tag from HTTPRoute resources.

The root cause is that IngressRule does not carry the tag name — it is only encoded in the hostname, forcing downstream controllers to reverse-parse it with fragile template-based heuristics.

This PR populates the new IngressRule.Tag field (added in knative/networking) with the traffic target name during route reconciliation, so that downstream ingress controllers can propagate the tag as labels on generated resources (e.g. HTTPRoute, HTTPProxy).

• 🎁 Add tag string parameter to makeIngressRules() and makeIngressRuleForHosts()
• 🎁 Set IngressRule.Tag from the traffic target name in makeIngressSpec()
• 🧹 Update tests to reflect the new Tag field on IngressRule

Related PRs

• feat: add Tag field to IngressRule networking#1116 (must be merged first — adds the Tag field to IngressRule)

Context

In knative-extensions/net-gateway-api#931, we attempted to add a tag label to HTTPRoute by reverse-parsing the hostname using the tag template. However, since the tag template format is highly configurable, this approach turned out to be fragile. We concluded that the upstream IngressRule should carry the tag name explicitly rather than relying on hostname heuristics.

Release Note

Populate `IngressRule.Tag` with the traffic target name so that downstream ingress controllers can identify the originating traffic tag on generated resources.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: kahirokunn
Once this PR has been reviewed and has the lgtm label, please assign skonto for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.22%. Comparing base (cff5211) to head (4878572).
⚠️ Report is 15 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #16437      +/-   ##
==========================================
+ Coverage   80.16%   80.22%   +0.05%     
==========================================
  Files         217      217              
  Lines       13503    13521      +18     
==========================================
+ Hits        10825    10847      +22     
+ Misses       2310     2309       -1     
+ Partials      368      365       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[knative-prow]

@kahirokunn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
build-tests_serving_main	4878572	link	true	/test build-tests
istio-latest-no-mesh_serving_main	4878572	link	true	/test istio-latest-no-mesh

Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[dprotaso]

/hold

see: knative/networking#1116 (comment)

[kahirokunn]

Following discussions on Slack, we will adopt this option.
#16455