feat: one-key client for the new private key

[sydneycollins-cio]

Update to support the new private key.

[sydneycollins-cio]

Tested locally at this PR's head (5077ea962c) against services 199c4a789c, CDP aa721dbec and edge af983b44, all at main. Keys were made through services' UI API and synced to CDP and edge the normal way. A pass-through proxy recorded the auth scheme and status. CDP ran in strict mode, so a bad key gets an error instead of 200.

Key	Call	Result
ak_	identify	Bearer, 200
ak_	track event	Bearer, 200
ak_	send email	Bearer, 200 on /v1/send/email
wk_	identify	Bearer, 200
wk_	send email	refused by the SDK (no transactional access), no request sent
legacy App API key	send email	Bearer, 200
legacy site ID + API key	old Track client identify	Basic, 200
revoked ak_	identify	401, SDK reports the key can't use Track

No key showed up in the SDK's output or logs. All passed.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 5077ea9. Configure here.}

[Shahroz16]

Approving from my side. Two small wording bits:

Could we avoid saying every 401/403 means the key can't do something? An IP restriction or a disabled workspace can return those too. The original error is still there, so a more general message should be enough here.

The README's “Legacy App API keys also work here” could use the Track limitation too: legacy keys work for transactional calls, but Bearer Track calls on Pipelines workspaces need a source-bound new key.

That's my take. Let's also get Bernard or the NF team to review this.