feat(gax): add helpers to detect and surface unsupported resumable upload configurations

[whowes]

gRPC clients bridge resumable uploads to HTTP/JSON using only top-level StubSettings; pre-built channels or transport providers with direct endpoint, credentials, or header overrides are currently silently ignored rather than surfacing an actionable error.

This PR adds

• HttpJsonCallableFactory.isResumableUploadSupported() to detect incompatible transport providers
• createFailingResumableUploadCallable() that throws a deferred exception when an upload or resume call is invoked (stub initialization continues to be successful) if an incompatibility or error was encountered during stub creation.

[gemini-code-assist]

Code Review

This pull request introduces ResumableUploadTransportValidator to validate transport configurations on StubSettings for resumable uploads, exposing helper methods via HttpJsonCallableFactory. A review comment suggests adding a defensive null check for the transport channel provider in ResumableUploadTransportValidator to prevent a potential NullPointerException.

[sonarqubecloud]

Quality Gate passed for 'gapic-generator-java-root'

Issues
10 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonarqubecloud]

Quality Gate failed for 'gapic-generator-java-root'

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[blakeli0]

Discussed offline that this may introduce false positives. Because we are always creating a new channel from StubSettings, as long as customers set the same headers/credentials/endpoints on the StubSettings as well, resumable upload should be supported.

On the other hand, I don't think there is a concrete way to decide if a customized grpc channel can be supported for resumable uploads. This check still provide some value and can be used for a warning message instead of a hard failure.