Support RBAC shadow / dry-run mode in SecurityPolicy authorization

Envoy's RBAC HTTP filter supports evaluating policies in "shadow" mode via [`shadow_rules`](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rbac_filter#role-based-access-control-rbac-filter). In this mode, Envoy evaluates policies against live traffic and emits metrics (`shadow_allowed`, `shadow_denied`) and dynamic metadata (`shadow_engine_result`, `shadow_effective_policy_id`) without actively blocking or rejecting client requests.

Currently, Envoy Gateway's `SecurityPolicy` CRD translates `spec.authorization` exclusively into active enforcement (`rules`). There is no native configuration to evaluate RBAC policies in shadow / audit mode. Configuring shadow rules currently requires resorting to `EnvoyPatchPolicy`.

First-class support for RBAC shadow mode directly in `SecurityPolicy` would provide a safer and native rollout path.

**Potential Solution**

Add an optional `mode` field to `SecurityPolicy.spec.authorization`:

```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
name: test-rbac
spec:
targetRef:
group: gateway.networking.k8s.io
kind: HTTPRoute
name: backend-route
authorization:
mode: Shadow # or "Enforce" (default)
defaultAction: Deny
rules:
- name: allow-admin
action: Allow
principal:
headers:
- name: x-role
values: ["admin"]
```

- When `mode: Shadow`, the Envoy Gateway translator would populate Envoy's `shadow_rules` instead of the active `rules` field in `envoy.extensions.filters.http.rbac.v3.RBAC`. Requests would not be denied by this policy, while Envoy emits the corresponding shadow metrics and dynamic metadata.
- When `mode: Enforce` (or when omitted for backward compatibility), the behavior remains unchanged, populating `rules`.

*Use Case*

1. **Safe Rollouts:** Validate new authorization rules against live traffic prior to active enforcement, mitigating the risk of accidental outages or false-positive denials.
2. **Auditing / Compliance:** Audit traffic against zero-trust policies to identify affected clients before enforcing restrictions.
3. **Avoid EnvoyPatchPolicy:** Eliminate the dependency on raw JSONPatches via `EnvoyPatchPolicy`, which are fragile across Envoy Gateway and Envoy version upgrades.

*References*

> Envoy RBAC Filter Documentation: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rbac_filter#role-based-access-control-rbac-filter
> Envoy RBAC v3 API (`shadow_rules`): https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/rbac/v3/rbac.proto

Start by tracing how SecurityPolicy.spec.authorization is translated into Envoy's RBAC v3 configuration, then compare the existing active rules path with the Envoy shadow_rules API. Check the related SecurityPolicy translation tests and EnvoyPatchPolicy behavior. Done means Shadow populates shadow_rules without blocking requests, while Enforce and the omitted mode preserve the existing rules behavior.

Written by the indexing model from the issue text.