Expose gRPC access-log buffering (buffer_size_bytes / buffer_flush_interval) on ProxyAccessLogSetting

*Description*:

Envoy Gateway builds `CommonGrpcAccessLogConfig` for the OpenTelemetry and ALS access-log sinks with only `LogName`, `GrpcService` and `TransportApiVersion` set (`buildXdsAccessLog`, `internal/xds/translator/accesslog.go`). `buffer_flush_interval` and `buffer_size_bytes` are never set, so both take Envoy's defaults of 1s and **16384 bytes**, and nothing on `ProxyAccessLogSetting` can change them: on `main` it carries `Format`, `Matches`, `Sinks` and `Type`, and nothing else. `backendSettings` tunes the connection to the sink rather than the access logger's own buffer.

The reason this matters is that `buffer_size_bytes` is not only the flush threshold. In Envoy's implementation it also becomes `max_buffer_size_bytes_`, the cap past which `canLogMore()` returns false and further entries are discarded against `logs_dropped`. Envoy holds and retries what fits in the buffer while a stream is unavailable — an Envoy maintainer confirms this on envoyproxy/envoy#40806, *"It will remain in the buffer. Envoy will keep trying to send it. The buffer needs to overflow and messages actually discarded for the metric to start being incremented"* — but the overflow is dropped. So the buffer size sets how long a sink can be unavailable before access logs are lost.

At 16 KB that window is very small on a busy proxy. A JSON access-log record of roughly 1 KB means the buffer holds on the order of fifteen entries, so a gateway serving a few thousand requests per second can absorb only tens of milliseconds of sink unavailability. That is shorter than an ordinary rolling restart of the collector or backend receiving the logs, so records are dropped on routine deployments rather than only in incidents.

Envoy already supports raising this; the gap is that Envoy Gateway does not surface it. Operators who use the OTLP access-log sink for anything they need to be complete — usage accounting, per-request billing records, audit trails — currently have no way to trade proxy memory for a larger tolerance window, even though the underlying proto has supported it for a long time.

The request is to expose `buffer_flush_interval` and `buffer_size_bytes` on `ProxyAccessLogSetting` (or on the individual sinks), passing them through to `CommonGrpcAccessLogConfig` and keeping Envoy's current values as the defaults so existing behaviour is unchanged.

Two things that would be useful to settle as part of this, if maintainers have a view: whether the setting belongs per-sink or per-`settings` entry, given one `settings` entry can carry several sinks; and whether it should apply to the `ALS` sink as well as `OpenTelemetry`, since both go through the same `CommonGrpcAccessLogConfig` path.

*Relevant Links*:

- [`CommonGrpcAccessLogConfig`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto) — `buffer_flush_interval` and `buffer_size_bytes` and their defaults
- https://github.com/envoyproxy/envoy/issues/40806 — maintainer confirmation that entries are buffered and retried while the stream is down, with the overflow dropped
- https://github.com/envoyproxy/envoy/pull/45263 — `grpc_entries_flushed` / `grpc_entries_flush_failed` stats, merged 2026-06-30, which make the loss observable but not avoidable

Start in internal/xds/translator/accesslog.go at buildXdsAccessLog and trace how ProxyAccessLogSetting becomes CommonGrpcAccessLogConfig for the OpenTelemetry and ALS sinks. Check the API definition for ProxyAccessLogSetting and settle whether buffering is per sink or settings entry; done means both fields are passed through while Envoy's current defaults remain unchanged.

Written by the indexing model from the issue text.