Enforce ReferenceGrant on cross-namespace Gateway API backendRefs

[Shine-neko]

Summary

Cross-namespace backendRefs on a Gateway API HTTPRoute were honoured unconditionally, letting any route author route traffic to any Service cluster-wide, without the target namespace's consent. This is non-conformant with the Gateway API spec and a privilege-escalation hole.

This change makes a cross-namespace backendRef require a ReferenceGrant in the target (Service) namespace that trusts the route's namespace. Without one, the backend is dropped (logged, and reflected as ResolvedRefs=False) instead of being routed. Same-namespace references are unaffected and never consult the grant set.

What changed

• New ReferenceGrant watcher (4th Gateway API watcher), tracking authorised (from_ns, to_ns) pairs in the shared GatewayScope. A grant appearing/disappearing re-resolves affected routes immediately via the existing changed notifier.
• BackendRefAuthorizer trait gates cross-namespace resolution in rule_to_entrypoints; the scope implements it (fail-closed on a poisoned lock).
• Only HTTPRoute -> Service grants count; a grant targeting another kind (e.g. Secret) does not authorise a backendRef.
• RBAC: adds the referencegrants read verb (docs + e2e deploy manifest).

Tests

• 5 new unit tests: refused without a grant, resolves with a grant, revoked on grant deletion, same-namespace never needs a grant, a Secret grant does not authorise a Service ref.
• e2e (02-gateway.sh): cross-namespace backend refused without a grant (404), served once a grant authorises it (200), refused again after the grant is deleted (404). Verified end-to-end on kind against a local image build: 26 passed, 0 failed.
• cargo fmt --check clean, clippy clean.

Docs

New "Cross-namespace backends (ReferenceGrant)" section in the Kubernetes provider docs, RBAC updated, and the "not implemented" lists corrected (ReferenceGrant removed; the stale claim that Gateway/GatewayClass were unimplemented fixed).