query-transport: empty bearer token is silently discarded instead of failing validation

[shalvirajpura2]

Observed behavior

QueryTransportSecret::try_new() in src/query/coordination.rs rejects empty and whitespace-only tokens. QueryTransportClientConfig::with_bearer_token() currently does:

self.bearer_token = QueryTransportSecret::try_new(token).ok();

The Err is converted to None. A caller that configures "" or " " therefore ends up with bearer_token: None, which is indistinguishable from not configuring a token at all.

The same pattern exists in TcpQueryCellClient::with_bearer_token().

Because the token is stored as None, QueryTransportClientConfig::validate() cannot reject the invalid configured value. This silently discards an invalid authentication configuration instead of surfacing it as a configuration error.

Why this is undesirable

An explicitly configured invalid token should fail validation rather than being silently discarded. Dropping the value hides the configuration error and can make the resulting behavior depend on whether the server allows unauthenticated requests.

Expected behavior

If a bearer token is configured and QueryTransportSecret::try_new() would reject it, the configuration should remain distinguishable from an unset token and validate() should fail.

The existing validation message, bearer token cannot be empty, is appropriate for this case.

Reproduction

let cfg = QueryTransportClientConfig::default()
    .with_bearer_token("   ")
    .insecure_allow_plaintext();

assert!(cfg.bearer_token.is_none()); // currently None
assert!(cfg.validate().is_ok()); // currently passes

The expected behavior is that the configured token remains present but invalid, and validation returns an error containing bearer token cannot be empty.

Code path

src/query/coordination.rs:

QueryTransportSecret::try_new() → QueryTransportClientConfig::with_bearer_token() → QueryTransportClientConfig::validate()

The same try_new(...).ok() pattern is also present in TcpQueryCellClient::with_bearer_token().