postgres: add Azure AD and GCP Cloud SQL IAM dynamic-auth backends

[reyortiz3]

Closes #261.

Summary

Adds two dynamic-auth backends alongside the existing AWS RDS IAM one, and generalizes the backend-dispatch plumbing (Config.Validate, NewAuthToken, NewDynamicAuthFunc) to support three backends cleanly via singleDynamicAuthBackend/countDynamicAuthBackends, instead of a single hardcoded AWS check. This also newly rejects a config with more than one backend set — previously unreachable with only one backend to choose from, but a real ambiguity risk now that there are three.

• DynamicAuthAzureAD — Entra ID (formerly Azure AD) tokens for Azure Database for PostgreSQL, via azidentity.DefaultAzureCredential's normal resolution chain (env vars, workload identity, managed identity, Azure CLI — AZURE_CLIENT_ID selects a user-assigned managed identity). Same BeforeConnect token-swap shape as AWS RDS IAM.
• DynamicAuthGCPCloudSQLIAM — OAuth2 tokens for GCP Cloud SQL IAM database authentication, minted from ambient Application Default Credentials. This is the direct-TCP token-swap path, not the Cloud SQL Go connector (cloudsqlconn): it requires the instance to have a reachable IP and does not get Cloud SQL's automatic mTLS tunnel. The connector is a structurally different piece of work (needs a DialFunc-based extension point this package doesn't have, not a BeforeConnect password swap) — deliberately out of scope here, per postgres: add Azure AD and GCP Cloud SQL IAM dynamic-auth backends #261.

Testing notes (read before assuming symmetry between the two backends)

• Azure: azidentity.NewDefaultAzureCredential's construction is credential-free — resolution is deferred to the first GetToken call — so azureADBeforeConnect is unit-tested the same way awsRDSIAMBeforeConnect already is (asserts a non-nil hook is returned; never invokes it, since invocation needs real credentials).
• GCP: verified empirically (not assumed) that google.DefaultTokenSource resolves Application Default Credentials eagerly and errors immediately when none are found, unlike AWS/Azure. That makes even "does the constructor return a non-nil hook" environment-dependent — a machine with real GCP credentials configured would get a different result than this dev sandbox did. So there's deliberately no equivalent invocation-level test for the GCP backend; the comment at the bottom of azuread_test.go explains why, rather than silently omitting coverage with no trace of the decision.

Verification

• go build ./..., go vet ./..., golangci-lint run ./... — all clean.
• go test ./postgres/... — all pass, including new cases for both backends and the multi-backend-configured rejection.
• govulncheck ./postgres/... — no vulnerabilities in code added by this PR (one pre-existing, already-tracked golang.org/x/crypto/openpgp finding unrelated to this change and not reachable from it — see issue Drop the GO-2026-5932 openpgp exclusion once rekor releases the migration #231).
• go mod tidy run; azcore/azidentity promoted from indirect to direct deps; golang.org/x/oauth2/google needed no new module dependency (already required at v0.36.0).

Not in this PR

• The GCP Cloud SQL Go connector (cloudsqlconn) — separate design decision per postgres: add Azure AD and GCP Cloud SQL IAM dynamic-auth backends #261.
• Unifying toolhive-registry-server's independent dynamic-auth implementation onto this package — flagged in postgres: add Azure AD and GCP Cloud SQL IAM dynamic-auth backends #261, unaddressed here.