e2e: no lane runs with gateway.enabled, so the platform's Gateway API publishing path is never installed in CI #4846

No e2e lane turns on the platform's gateway.enabled, so nothing that flag switches is ever installed in CI. The default is false in packages/core/platform/values.yaml, and neither hack/e2e-install-cozystack.bats nor any workflow sets it. The gateway chainsaw suite still runs, because it creates tenants with gateway: true and drives their TenantGateway directly. The platform publishing path behind the flag stays off.

What CI never renders because of that:

• the passthrough listeners of the publishing tenant (tls-api, tls-vm-exportproxy, tls-cdi-uploadproxy) in packages/extra/gateway/templates/tenantgateway.yaml
• the platform TLSRoutes of cozystack-api, kubevirt vm-exportproxy and kubevirt-cdi uploadproxy
• the HTTPRoutes of dashboard, keycloak, grafana and alerta, which replace their Ingresses
• the http01.gatewayHTTPRoute solver in the cert-manager ClusterIssuers
• the namespace.cozystack.io/gateway label on tenant-root from cozystack-basics

I hit this while checking whether the gateway suite catches regressions in #4638. A mutation that rendered the passthrough services on every tenant instead of only the publishing one stayed green in e2e. With the flag off no tenant renders them, so the check in the suite could not tell the two apart. helm-unittest caught it, and that is enough for the template itself. But none of the objects above ever meets a real Cilium, cert-manager or apiserver in CI.

A lane or a suite run with gateway.enabled: true would close this. Traffic through the api TLSRoute is tracked separately in #2478.