ext_proc gRPC authority should use Backend FQDN hostname, not CRD name

## Problem

When using `EnvoyExtensionPolicy` with ext_proc `backendRefs` pointing to a `Backend` CRD with FQDN endpoints, the generated gRPC `authority` is set to `.` instead of the FQDN hostname from the Backend spec.

Example Backend:
```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: Backend
metadata:
name: my-ext-proc
namespace: envoy-gateway-system
spec:
endpoints:
- fqdn:
hostname: my-service.example.com
port: 443
```

Expected authority: `my-service.example.com`
Actual authority: `my-ext-proc.envoy-gateway-system`

## Impact

When the ext_proc service is behind a reverse proxy that routes based on the `:authority` header (e.g., Istio ingress gateway, nginx), the incorrect authority causes routing failures. The request reaches the proxy but gets rejected because no virtual host matches `my-ext-proc.envoy-gateway-system`.

## Current Workaround

```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyPatchPolicy
spec:
targetRef:
group: gateway.networking.k8s.io
kind: Gateway
name: my-gateway
type: JSONPatch
jsonPatches:
- type: "type.googleapis.com/envoy.config.listener.v3.Listener"
name: my-namespace/my-gateway/https
operation:
op: replace
jsonPath: "..http_filters[?match(@.name, .*extproc/0.*)].typed_config.grpc_service.envoy_grpc"
path: "authority"
value: "my-service.example.com"
```

## Proposed Solution

When a `Backend` CRD with FQDN endpoints is used as a `backendRef` in `EnvoyExtensionPolicy.extProc`, use the FQDN `hostname` as the gRPC `authority` instead of the Kubernetes-style `.` format.

Alternatively, add an explicit `authority` field to the ext_proc spec:
```yaml
extProc:
- backendRefs:
- group: gateway.envoyproxy.io
kind: Backend
name: my-ext-proc
authority: my-service.example.com
```

## Environment

- Envoy Gateway v1.7.2
- Backend CRD with FQDN endpoints behind Istio ingress gateway
- ext_proc services in remote clusters accessed via service mesh ingress