fix(gatewayapi): grant WAF filter licensekey access for both API groups

[electricjesus]

Description

In clusters installed in "no API server" mode (USE_API_SERVER=false in banzai; only projectcalico.org/v3 direct CRDs installed, no crd.projectcalico.org/v1 CRDs), libcalico-go's clientv3 auto-discovers the v3 API group and queries it directly. The WAF HTTP filter sidecar's license monitor was denied access because the waf-http-filter ClusterRole only granted the crd.projectcalico.org group.

The denial caused license init to fail, leaving the filter's ingressGatewayEnabled at its zero value (false), which routes all requests through the unlicensed handler — bypassing WAF rule processing. The result is a silent fail-open: attacks like SQLi/XSS go through unblocked.

This change extends the ClusterRole's APIGroups to include both groups so the filter can read the LicenseKey regardless of which CRD set the cluster installed.

Verification

Reproduced end-to-end on a kubeadm cluster installed with v3 CRDs only (mirroring banzai's USE_API_SERVER=false flow):

Before fix (only crd.projectcalico.org granted):

Failed to load product license from datastore.
licensekeys.projectcalico.org "default" is forbidden:
User "system:serviceaccount:tigera-gateway:waf-http-filter" cannot get
resource "licensekeys" in API group "projectcalico.org" at the cluster scope
Failed to refresh license, license enforcement disabled

After fix (both groups granted):

License status check complete ingress-gateway-enabled=true license-status="valid"
Ingress Gateway feature is properly licensed - all features available

Test in pkg/render/gatewayapi/gateway_api_test.go updated to assert both groups.

EV-6590

Fix WAF HTTP filter failing open in clusters installed without the Calico API server (USE_API_SERVER=false / v3-CRDs-only mode). The filter's license check now succeeds regardless of which Calico CRD group is installed, so WAF rule processing engages as intended.