grpc_json_transcoder: unknown JSON body fields are dropped silently with no validation option — is an opt-in strict mode or a surfaced drop in scope?

Hi, and thanks for the transcoder filter — this is a question about validation scope and visibility, not a bug report.

When a JSON request to `envoy.filters.http.grpc_json_transcoder` carries a field the target protobuf message does not define, the filter drops it while transcoding to protobuf and forwards the RPC. The client receives `200 OK` and the upstream receives a well-formed message; neither side is told a field was discarded.

### Minimal reproduction

Service with a message that names two fields:

```proto
message Command {
string action = 1;
int32 amount = 2;
}
service Gateway {
rpc Send(Command) returns (Ack) {
option (google.api.http) = { post: "/v1/send" body: "*" };
}
}
```

Transcoder in front of a gRPC upstream. Then:

```
POST /v1/send {"action":"transfer","amount":1,"auth":"...."}
```

The upstream receives only `action` and `amount`; the `auth` field is gone, and the response is `200 OK`. Measured on **Envoy 1.31.10** (`envoyproxy/envoy:v1.31-latest`).

### The part worth asking about

`GrpcJsonTranscoder.request_validation_options` offers three switches —
`reject_unknown_method`, `reject_unknown_query_parameters` and
`reject_binding_body_field_collisions` — and none concerns an unknown field in the
JSON request **body**. I enabled `reject_unknown_method` and
`reject_unknown_query_parameters` together and the request carrying an unknown body
field still returned `200 OK` with the field dropped. So, unlike grpc-gateway and
connect-go, there appears to be no configuration on this filter that rejects it.

### Questions

1. Is the absence of a body-field validation option deliberate — i.e. is silently dropping unknown JSON body fields considered the correct behaviour for the proto3 JSON mapping here?
2. Would an opt-in strict mode be in scope — for example a `reject_unknown_body_fields` under `request_validation_options`, mirroring the existing method/query switches?
3. Failing that, would surfacing the drop (a filter metric or an access-log field for discarded body fields) be in scope, so an operator can notice it without a config option?

For context: grpc-gateway (grpc-ecosystem/grpc-gateway#7220) and connect-go (connectrpc/connect-go#954), which apply the same JSON mapping, both drop by default too, but each exposes a way to reject (a marshaler option and a replacement codec respectively). Envoy is the one stack among the three where I could find no such control, which is why I am asking whether an opt-in or a visibility signal is in scope rather than reporting a defect. Happy to share the reproduction if useful.

Start with Envoy's GrpcJsonTranscoder request_validation_options and reproduce the behavior described for Envoy 1.31.10 using the supplied proto and POST request. Review how unknown JSON body fields are handled and determine whether strict rejection or drop visibility is the intended scope; done requires a decided behavior and corresponding implementation or documented resolution.

Written by the indexing model from the issue text.