feat(core): Snowflake Cortex OAuth login for V2

[686f6c61]

Issue for this PR

Closes #34780

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

V2 already has Snowflake Cortex as a catalog provider with PAT/env auth, but it never registered the browser OAuth login that V1 had. Without that, users cannot connect via Snowflake's external-browser OAuth, and the account-scoped Cortex host never ends up on the request.

This ports the V1 flow into the V2 snowflake-cortex plugin:

• browser OAuth with account + optional role prompts
• PKCE authorize/token exchange against https://{account}.snowflakecomputing.com
• refresh using credential.metadata.accountId
• store { accountId, baseURL } on the OAuth credential

It also teaches fromCatalogModel to apply OAuth routing metadata: for Snowflake, derive the Cortex OpenAI-compatible base URL from accountId (or use an explicit metadata.baseURL). Key credentials still project metadata into the request body; OAuth metadata is not dumped into the body.

Why this works: Snowflake OAuth is account-hosted, so refresh and API calls need the same account id that login captured. Putting that on credential metadata and resolving api.url at request time matches how V1 stashed accountId and built the host in the loader, without reintroducing a V1-style fetch monkey-patch for the native path.

How did you verify your code works?

• bun test test/plugin/provider-snowflake-cortex.test.ts test/session-runner-model.test.ts (33 pass): method registration, account/role helpers, cortexFetch quirks, OAuth baseURL + bearer resolution
• monorepo typecheck via pre-push hook
• not runtime-tested against a real Snowflake tenant (no account available)

Screenshots / recordings

N/A (no UI change)

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[anujbolewar]

looks reasonable for a local oauth flow — pkce + a callback server bound to 127.0.0.1 is the standard safe pattern. one q: if the user misses the 5min window, do they just get an error or can they restart the flow cleanly?

[686f6c61]

Good question.

On the 5-minute window they get a hard error from the OAuth callback: Snowflake OAuth callback timeout - authorization took too long. The local callback server is closed via the authorize-scope finalizer, so the port is released.

There is no mid-flow resume after that timeout: the failed attempt is discarded. Starting Login with Snowflake again runs a fresh authorize (new PKCE, state, and 127.0.0.1 listener), so the flow restarts cleanly without leftover callback state from the timed-out attempt.