[Bug] Proxy gRPC client settings should tolerate malformed metric collector address

### Bug description

When the proxy is configured with `metricCollectorMode=on`, `GrpcClientSettingsManager.mergeMetric` parses `metricCollectorAddress` with `split(":")` and directly reads `split[1]` / `Integer.parseInt(split[1])`.

If `metricCollectorAddress` is empty, missing the port, or has a non-numeric port, the gRPC client settings path can throw runtime exceptions while constructing the `Metric` settings response:

- empty or host-only value: `ArrayIndexOutOfBoundsException`
- non-numeric port: `NumberFormatException`

This makes a malformed optional metrics collector config affect normal gRPC client telemetry/settings negotiation.

### Expected behavior

The proxy should not fail gRPC client settings generation because the optional client metric collector endpoint is malformed. It should reject/ignore the malformed endpoint and return settings with client metrics disabled, while keeping valid `host:port` values unchanged.

### Affected area

`proxy` module, gRPC v2 client settings / telemetry path.

### Suggested fix

Validate `metricCollectorAddress` before constructing `Endpoints`:

- require non-blank `host:port`
- require a numeric port
- on invalid values, log a warning and set `Metric.on=false`
- add unit tests for valid, empty, missing-port, and non-numeric-port addresses

Start at GrpcClientSettingsManager.mergeMetric in the proxy module and trace how metricCollectorAddress becomes the Metric settings response. Add unit tests for valid, empty, host-only, and non-numeric-port addresses; done means malformed optional endpoints no longer throw, disable client metrics, and valid host:port values remain unchanged.

Written by the indexing model from the issue text.