gateway: TLSRoute manifests and the controller stay on v1alpha2 while the bundle stores v1 #4067

Problem / motivation
Three manifests render TLSRoute at gateway.networking.k8s.io/v1alpha2: packages/system/cozystack-api/templates/api-tlsroute.yaml:6, packages/system/kubevirt/templates/vm-exportproxy-tlsroute.yaml:6, packages/system/kubevirt-cdi/templates/cdi-uploadproxy-tlsroute.yaml:6. The bundle stores v1 and marks v1alpha2 deprecated. packages/system/cozystack-api/tests/api_route_test.yaml:53 pins the deprecated value, so a bundle that drops it arrives as a red test plus three broken manifests.

The manifests cannot move alone. go.mod pins sigs.k8s.io/gateway-api v1.4.1, which has TLSRoute only under apis/v1alpha2 and apis/v1alpha3, so the tenant-gateway controller lists, watches and patches status through v1alpha2.

Proposed solution
One change for the whole TLSRoute surface: bump sigs.k8s.io/gateway-api to a release with apis/v1.TLSRoute, move the controller, then the three manifests and the test pin. The v1 schema adds minItems: 1 on spec.hostnames; the controller's hostname-less handling needs checking against that first.

Scope check

• This affects a single component / package (controller, three system packages, the Go module)
• I can describe the expected behavior concretely

Alternatives considered
Moving the manifests alone makes the tree less consistent than it is now. Staying on v1alpha2 until the bundle drops it is the status quo; the test pin makes that loud, so this is cleanup with a known trigger.

Additional context
Surfaced while reviewing #3872.