Pass configured AWS region to STS credential exchange

[melissa-barca]

Fixes #14546

The auth extension resolved the AWS region but never passed it along, so the AWS SDK always targeted us-east-1 when fetching credentials. It now passes the region through fromNodeProviderChain's clientConfig, so the SDK uses it.

Also moves the per-provider credential helpers (aws, googleVertex, snowflake) into a credentials/ subfolder.

Release Notes

New Features

• N/A

Bug Fixes

• Fix Bedrock ignoring the configured AWS region when signing in (Bedrock STS region falls back to us-east-1 #14546)

Validation Steps

@:posit-assistant

No e2e coverage: reproducing requires a region-restricted VPC where STS PrivateLink covers only a non-default region. Unit coverage for the region-resolution logic lives in extensions/authentication/src/test/aws.test.ts.

[github-actions]

E2E Tests 🚀
This PR will run tests tagged with: @:critical @:posit-assistant

^{readme  valid tags}

[github-actions]

PETE's assessment 🧪

Verdict: 🟢 Adequate -- The one substantive change (passing the resolved region into the STS clientConfig) is extracted into a pure function and pinned by a new regression test covering all four resolution branches; everything else is a behavior-preserving file move.

What changed

• Bug fix (Bedrock STS region falls back to us-east-1 #14546): AWS region is now threaded into fromNodeProviderChain's clientConfig so the STS credential exchange targets the configured region instead of always us-east-1. The resolution logic was extracted into a pure resolveAwsChainInit() (credentials/aws.ts).
• Moved the per-provider credential helpers (aws/googleVertex/snowflake) into a credentials/ subfolder behind a barrel index.ts; ~7 files are pure import-path updates.

Tests in this PR

• Unit (Vitest/Mocha) ✅ (added aws.test.ts; googleVertex.test.ts / snowflake.test.ts updated for new paths)
• Extension host ✅ (aws.test.ts is an ext-host Mocha suite exercising the resolver)
• E2E (Playwright) ✅ (not applicable -- no rendered UI; repro needs a region-restricted VPC)

Existing coverage

The moved google/snowflake helpers retain their existing suites (test/googleVertex.test.ts, test/snowflake.test.ts), updated only for the renamed import paths -- behavior-preserving, so existing coverage stands.

Suggested additions

None. The new test/aws.test.ts is a genuine regression test: it asserts chainInit.clientConfig.region for the setting-wins, env-fallback, default-fallback, and profile-set cases -- the exact branch the fix touches. It would fail against main (which never set clientConfig).

Deployment note (optional)

The fix guards a bug that only manifests in a region-restricted VPC (STS PrivateLink), which no PR-time e2e can reasonably reproduce -- the author correctly notes this. The behavior is process-env/config logic with no web (isWeb, browser/) or Windows (path/process) hotspots in the diff, so unit coverage is sufficient and no surface-specific test is warranted.

---

PETE (Positron Extreme Test Experiment) - LLM-based test-coverage advisor, in pilot. Triggers on PR open and on /recheck-tests comments. Wrong verdict? Comment /recheck-tests (or /rePETE) on this PR to re-run. Please share feedback on how PETE performed here.

[sharon-wang]

There's an issue with resolveAwsChainInit for AWS SSO login, otherwise some minor comments!

[sharon-wang]

Should this and the equivalent snowflake file import from credentials directly, now that we have the index.ts file exporting everything?

Suggested change

	import { resolveGoogleVertexCredential } from '../credentials/googleVertex';
	import { resolveGoogleVertexCredential } from '../credentials';

[sharon-wang]

should we move this logging into resolveAwsChainInit? Then we wouldn't need to return region/profile from resolveAwsChainInit either, since it's not directly used here anymore

[sharon-wang]

This isn't working for me when my SSO region is different than my AWS profile region, because it overwrites the region I have configured in ~/.aws/config to the same region as the AWS profile.

For example, if my AWS profile region is not configured to something specific, then the region defaults to us-east-1. But if my SSO region is actually us-east-2, chainInit sets the region to us-east-1, which causes the SSO authentication to fail.

This works for me, but I'm not certain about the STS case:

Suggested change

	const chainInit: ChainInit = {
	...(profile ? { profile } : {}),
	clientConfig: { region },
	};
	// The region is passed to the STS `clientConfig` only when web identity token
	// auth is in use (AWS_WEB_IDENTITY_TOKEN_FILE set), so the STS exchange targets
	// the configured region. For SSO profiles, the region is read from sso_region
	// in ~/.aws/config and must not be overridden via clientConfig.
	const chainInit: ChainInit = {
	...(profile ? { profile } : {}),
	...(env.AWS_WEB_IDENTITY_TOKEN_FILE ? { clientConfig: { region } } : {}),
	};