Drop getAzurePATForOAuthToken's base64 when upgrading to @gitkraken/provider-apis 0.59.0

Summary

GKDEV-3618 moved the HTTP Basic encoding into @gitkraken/provider-apis (released in 0.59.0). isPAT now sends base64(':' + token); it previously placed the token after Basic verbatim, which is not a valid Basic credential, so this repo encoded the pair itself.

That encoding now double-encodes and will fail authentication. It has to be removed in the same change that raises the dependency.

Current state

pnpm-workspace.yaml pins the catalog entry at 0.58.0, so nothing breaks until that is raised. The workaround is a single helper in packages/core/src/plus/integrations/providers/providersApi.ts:

private getAzurePATForOAuthToken(oauthToken: string) {
	return base64(`PAT:${oauthToken}`);
}

It is called from the Azure reads that only accept a PAT (getAzureProjectsForResource, plus the two pull-request paths that pass isPAT: true explicitly after deriving the token), each shaped as:

const azureToken = options?.isPAT ? token : this.getAzurePATForOAuthToken(token);

Note the branch: when the caller already passed isPAT, the token is forwarded untouched, so that path is fixed by the SDK change and needs nothing. It is the OAuth branch, which derives a PAT-shaped credential through the helper, that must stop encoding.

What to do

1. Raise the @gitkraken/provider-apis catalog entry to 0.59.0 or later.
2. Make getAzurePATForOAuthToken return the token unencoded, at which point it is the identity function and the call sites can drop it, keeping isPAT: true on the calls that set it.
3. Check whether the base64 import in that file is still used, and remove it if not.

Verification

Reads and writes were exercised against a live Azure DevOps organization on the SDK side: projects, repositories, pull requests and work items all authenticate with a raw PAT and isPAT, and the pre-encoded form is refused. The equivalent check here is that the Azure integration still works once the helper stops encoding.

Worth knowing while testing: a bad credential can currently look like a successful write. Azure answers one with HTTP 203 and an HTML sign-in page, which the SDK's request layer treats as success, so on a route returning void nothing surfaces at all (tracked as GKDEV-3617). Assert by reading state back rather than trusting that a call did not throw.

Do not raise the dependency without this change in the same commit.

Related: GKDEV-3619 is the equivalent migration for gitkraken.dev.