Workflow [PR], commit [54f5740]

QA Verification

This change is difficult to validate end-to-end with a real Polaris setup, as Polaris is not trivial to deploy locally and there is no existing automated coverage for this specific OAuth behavior.
This PR does not have a corresponding issue and does not introduce new automated tests.

To validate the fix, a local mock OAuth + REST catalog server was implemented to strictly validate application/x-www-form-urlencoded requests and require proper URL-encoding of OAuth parameters.

Behavior comparison

Before (current Antalya Docker release):

=== /oauth/token ===
Content-Type: application/x-www-form-urlencoded
Raw body: grant_type=client_credentials&scope=PRINCIPAL_ROLE:ALL&client_id=clientid&client_secret=my/secret+value
172.22.0.2 - - [19/Dec/2025 13:13:28] "POST /oauth/token HTTP/1.1" 400 -

After (this backport applied):

=== /oauth/token ===
Content-Type: application/x-www-form-urlencoded
Raw body: grant_type=client_credentials&scope=PRINCIPAL_ROLE%3AALL&client_id=clientid&client_secret=my%2Fsecret%2Bvalue
127.0.0.1 - - [19/Dec/2025 09:30:41] "POST /oauth/token HTTP/1.1" 200 -
127.0.0.1 - - [19/Dec/2025 09:30:41] "GET /v1/config?warehouse=demo HTTP/1.1" 200 -

This confirms that the OAuth request parameters are now properly URL-encoded and that ClickHouse successfully retrieves the access token and proceeds with authenticated REST catalog calls.

CI results

There is no dedicated automated coverage for this specific OAuth behavior, so CI results were reviewed for regressions.

Upstream CI for the original PR was not fully green. The backport CI also reported failures; however, they are consistent with upstream and previously known issues on the branch (e.g. test_async_load_databases) and are unrelated to REST catalog or OAuth functionality.

Given the limited scope of the change (OAuth request formatting), this backport is considered safe and does not introduce regressions.