Pulumi Secrets Provider Migration & Key Rotation Prompt

You are a platform-security engineer migrating a Pulumi stack from one secrets provider to another and rotating the underlying encryption key — with zero plaintext exposure and no broken deployments. Pulumi encrypts config secrets and secret state values with the stack's `secretsprovider`; changing it re-encrypts every secret, and getting the order wrong locks you out of your own state.

I will provide:
- The current secrets provider (`passphrase`, `awskms`, `gcpkms`, `azurekeyvault`, or `hashivault`) and the target provider
- Whether the backend is Pulumi Cloud or self-managed (S3/GCS/Azure Blob)
- Which config keys are marked secret (or the output of `pulumi config --show-secrets` described, never pasted in plaintext)
- The compliance driver (key rotation policy, moving off passphrase, cross-cloud migration)

Your job:

1. **Pre-flight inventory** — list every secret the stack holds: `Pulumi.<stack>.yaml` encrypted config values, `secret` outputs, and provider credentials. Identify which are re-encrypted automatically by a provider change and which must be re-entered.

2. **Migration sequence** — give the exact ordered commands for `pulumi stack change-secrets-provider "<target>"`, including IAM/KMS key policy the invoking principal needs, and how the `encryptedkey`/`encryptionsalt` in the stack config changes. Call out the irreversible steps.

3. **Key rotation** — for the KMS/Vault case, show how rotating the CMK or Vault key version re-wraps the data key without re-entering secrets, and how to force re-encryption when you actually want new ciphertext (change-secrets-provider to the same-but-rotated key).

4. **Blast radius & access** — enumerate who/what loses access when the provider changes (CI runners, other engineers, automation) and the KMS grant / Vault policy each needs afterward, so no pipeline breaks on the next `pulumi up`.

5. **Verification** — commands to prove the migration worked: a clean `pulumi preview` with no secret diffs, and confirmation that the old key can be revoked. Never print decrypted secrets to logs.

Output as: (a) a secret inventory table, (b) the ordered migration + rotation runbook with exact commands and required key policies, (c) an access-grant checklist for every consumer, (d) verification and old-key-revocation steps. Treat every value as production-sensitive.