secrets: providers are `env`, `file`, `keychain`, `op`, `command`, and `vault`; a deployment on AWS, GCP, or Azure has no native provider and falls back to `command`

Observed behavior

At eb8172f, pkg/flowstate/v1/secrets registers six schemes: env, file, keychain (macOS), op (1Password), command, and vault (in its own package). #244 wired the last three into deployments and is closed. There is no provider for AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault, which is where the secrets of most cloud deployments live; the command provider is the documented escape hatch, so the practical answer today is a shell script that calls the cloud CLI per secret, with the process-spawn, timeout, and scrubbing costs the command provider's own comments describe.

The credential half already exists in the tree: auth/exchange_cloud.go holds AWSConfig and GCPConfig for federation, and credentialsource resolves ambient CI identities. A native provider is the read half of a path the write half already walks.

Desired outcome

• secrets/awssm, secrets/gcpsm, secrets/azurekv, each its own Go module (as the plugins are, so the SDKs do not join the root graph), implementing Provider with: reference syntax awssm://<name>[#json-key], gcpsm://projects/…/secrets/…/versions/latest, azurekv://<vault>/<name>; namespace isolation through the existing SecretAccessPolicy (a tenant's references are matched before any fetch, fail-closed); the fetch bounded by the identity egress policy and a response cap; caching through the existing secrets.Cache with the provider's version or ETag as the key.
• Credentials come from the platform's ambient identity (IRSA, workload identity, managed identity) by default, with the federation exchange as the explicit alternative, never from a static key in the trust policy.
• flow secrets check <ref> (or the existing rehearsal verb) resolves one reference through the provider and prints only whether it resolved, never the value.

Acceptance criteria

• Each module has a conformance test against the provider's local emulator or a recorded HTTP fixture, run in deep.yml, covering resolve, not-found, denied-by-policy, and a response over the cap.
• secretstest's isolation suite (tenancy_test.go, isolation_test.go) runs against each provider unchanged.
• docs/DEPLOYMENT.md lists the six plus three schemes in one table with the ambient-credential shape each expects.

Constraints and dependencies

• Adjacent: #244 (closed; the wiring), secrets/vault (the shape to copy), auth/exchange_cloud.go, invariant 7 (values stay worker-side) and invariant 10 (cloud providers are optional integrations).

Start with pkg/flowstate/v1/secrets, secrets/vault, auth/exchange_cloud.go, and the existing Provider, Cache, and SecretAccessPolicy interfaces. Run the secretstest isolation suite in tenancy_test.go and isolation_test.go, then inspect deep.yml and the rehearsal verb before evaluating provider conformance tests. Done means three isolated Go modules, passing emulator or recorded-fixture tests, unchanged isolation coverage, the rehearsal check, and the docs/DEPLOYMENT.md table.