SNI `forward_to_virtual_cluster` config variant missing `destination` field in schema

### Title

`forward_to_virtual_cluster` policy with `type: sni` has no way to specify destination virtual cluster

### Labels

`enhancement`, `event-gateway`, `schema`

### Body

**Description**

The `forward_to_virtual_cluster` listener policy supports two config variants: `port_mapping` and `sni`. The `port_mapping` variant has a `destination` field that binds the policy to a specific virtual cluster. The `sni` variant does NOT have this field in the kongctl schema — confirmed by `kongctl explain event_gateway --output yaml`.

The REST API's SNI forward policy also doesn't take a `destination` — it routes based on the SNI hostname matching a virtual cluster's `dns_label`. This works, but it means there is **no way to declaratively manage an SNI listener via kongctl** since the binding happens implicitly.

**Environment**

- kongctl: latest (Homebrew)
- Confirmed via: `kongctl explain event_gateway --output yaml`
- Date tested: 2026-07-14

**Input configuration (best-effort attempt)**

```yaml
listeners:
- ref: sni-listener
name: sni-listener
addresses:
- 0.0.0.0
ports:
- 19400
policies:
- ref: sni-tls
type: tls_server
name: sni-tls
config:
certificates:
- certificate: "$ORDERFLOW_SNI_CERT"
key: "$ORDERFLOW_SNI_KEY"
- ref: sni-forward
type: forward_to_virtual_cluster
name: sni-forward
config:
type: sni
advertised_port: 19400
sni_suffix: ".127-0-0-1.sslip.io"
broker_host_format:
type: shared_suffix
# destination: ??? ← no field available in the sni variant
```

**REST API equivalent (works correctly)**

```bash
curl -X POST "$KONNECT_API/v1/event-gateways/$EG_ID/listeners/$LISTENER_ID/policies" \
--fail-with-body -H "Authorization: Bearer $KONNECT_TOKEN" \
--json '{
"type": "forward_to_virtual_cluster",
"name": "sni-forward",
"config": {
"type": "sni",
"advertised_port": 19400,
"sni_suffix": ".127-0-0-1.sslip.io",
"broker_host_format": {"type": "shared_suffix"}
}
}'
```

This REST call succeeds and routes correctly (using each virtual cluster's `dns_label` to match the SNI hostname prefix).

**Expected behavior**

Either:
1. The `sni` config variant should accept a `destination` field (or an array of destination virtual clusters) so the full listener configuration is declaratively manageable, OR
2. The SNI forward policy should be documented as automatically routing to all virtual clusters on the same Event Gateway by `dns_label` matching, and `kongctl apply` should support this "no destination" pattern cleanly (not requiring a `destination` that doesn't exist in the schema)

**Actual behavior**

Applying the file above through `kongctl apply` creates the SNI forward policy but it has no binding to any virtual cluster — the policy validates but doesn't produce a working routing setup in the same way the REST API does.

**Workaround**

Use the REST API for Step 9 (SNI routing). The `kongctl` file can declare everything through Step 8, but the SNI listener must be managed via curl.

Start with `kongctl explain event_gateway --output yaml` and the `kongctl apply` path for `forward_to_virtual_cluster` policies, comparing the `port_mapping` and `sni` variants with the REST API example. Determine whether SNI routing should expose a destination or support the no-destination pattern, then verify that the chosen behavior can be declared and applied consistently.

Written by the indexing model from the issue text.