[Fix] IAM: Fix cross-tenant agency AK/SK auth

[TobiWo]

What this PR does / why we need it

Fixes cross-tenant agency AK/SK authentication, which failed in two places. First, authWithAgencyByAKSK used the agency token flow (tokens3.Create) and cleared client.AKSKAuthOptions.AccessKey, leaving the client without credentials to sign with on retry. It now obtains a temporary AK/SK through the IAM assume_role credential flow and re-authenticates via v3AKSKAuth, so
requests stay AK/SK-signed and re-sign correctly on reauth.

• Replace token-based agency auth with credentials.CreateTemporary
• Re-run v3AKSKAuth using the temporary AK/SK and security token
• Scope to delegated project when set, otherwise to the agency domain
• Keep AccessKey instead of clearing it
• Add tests for delegated-project and domain-scope agency paths, including reauth

The temporary-AK/SK change then exposed a second failure: the re-authentication signed GET /v3/auth/catalog with the assumed-role identity, which OTC returns 403 for. That second fetch is redundant — the first pass (build-user AK/SK)
already built a working, region-global EndpointLocator from an identical catalog. v3AKSKAuth now takes a reuseEndpointLocator flag; the second agency pass skips the forbidden fetch and reuses the existing locator. Plain AK/SK and
the first agency pass are unchanged.

• Add reuseEndpointLocator to v3AKSKAuth; skip the catalog re-fetch on the assumed-role pass and reuse the first pass's EndpointLocator
• Assert in the agency tests that /v3/auth/catalog is never fetched with thetemporary AK/SK

Which issue this PR fixes

• fixes [IAM] Cross-tenant agency AK/SK auth uses tokens instead of temporary AK/SK #954

Special notes for your reviewer

Pre-existing, out of scope: when no delegated project is given, v3AKSKAuth swallows a failed agency-domain lookup and leaves DomainID empty rather than erroring (openstack/client.go:300-307). A wrong agency-domain name passes auth and fails on the first call instead. Since v3AKSKAuth is shared by all AK/SK paths, I'd fix it in the agency caller in a follow-up. Happy to pick it up.

[artem-lifshits]

This introduces a data race: ReauthFunc rewrites client.AKSKAuthOptions while every request reads it unlocked when signing (provider_client.go:291-305).

The old code never hit this path because it cleared AccessKey. go test -race shows it right away.

[TobiWo]

The race is real. Signing reads client.AKSKAuthOptions.* unlocked (provider_client.go:291-303), and ReauthFunc writes those same fields. reauthenticateAndRetry holds client.mut around ReauthFunc, but a first-time request signs in doRequest without taking that lock, so a concurrent sign and reauth can hit it together. The old token path avoided this by clearing AccessKey and skipping the signing block; we can't, because retries need AccessKey to re-sign.

One caveat for the thread: the suggested replacement doesn't fully close it. It swaps a whole-struct assignment for field-by-field writes, which shrinks the window, but those writes are still unlocked and still race the unlocked reads.
There is no locked setter for AK/SK options; only SetToken/Token guard anything. go test -race passes here only because the tests never sign a request while a reauth is running.

Decision: take the snippet now for the smaller window, and track the real fix separately: a locked accessor around the AK/SK signing reads and reauth writes in provider_client.go. That touches the signing path for every service, so it's out of scope for a hotfix. Pre-existing gap, not something this PR introduced. I will create a follow-up issue if you agree.

[artem-lifshits]

Agreed it's real but it's not pre-existing. This PR makes it reachable (old code cleared AccessKey and signing was skipped).
I'm fine to merge it and fix in the next issue.