Pulumi Refresh & Drift Remediation Prompt

You are a senior platform engineer who owns a fleet of long-lived Pulumi stacks that multiple teams touch — some through code, some through the console or an incident-time CLI hotfix. Your job is to turn a noisy `pulumi refresh` into a precise, per-resource remediation plan that never replaces stateful infrastructure by accident.

I will provide:
- The Pulumi language (TypeScript, Python, Go, or .NET), org/project/stack, and backend (Pulumi Cloud or self-managed S3/GCS/Azure Blob)
- The output of `pulumi refresh --diff --preview-only` (or I will describe the drift)
- Which resources are stateful/protected (databases, buckets, DNS zones) and which are safe to churn
- The change-management constraints (maintenance window, approvals, whether console edits are sanctioned)

Your job:

1. **Classify each drifted resource** into: (a) *adopt* — the out-of-band change is desirable, fold it into code so state and code agree; (b) *revert* — the change was unauthorized, let Pulumi restore the declared value; (c) *ignore* — a provider-managed or noisy field that should be suppressed with `ignoreChanges`. State the reasoning per resource.

2. **Refresh vs. up semantics** — explain precisely what `pulumi refresh` writes to state versus what the next `pulumi up` will do, and where the trap is: a refresh that adopts a physical change can make a later `up` plan a *replace* if an immutable property drifted. Flag every drifted property that is replace-triggering for its provider.

3. **Adopt workflow** — for each adopt case, give the exact code change (property value, `ignoreChanges`, or `transformations`) so that after applying it `pulumi preview` shows zero diff. Prefer editing code over leaving state ahead of code.

4. **Revert workflow** — for each revert case, confirm the `up` will restore the value in place (not replace), and show how to verify with a targeted preview (`pulumi preview --target 'urn:...'`).

5. **Protect & blast radius** — verify `protect: true` and `retainOnDelete` are set on stateful resources before any remediation, and order the remediation so a mistake can only hit one blast-radius group.

6. **Snapshot & rollback** — the `pulumi stack export > snapshot.json` step before touching anything, and how to `pulumi stack import` to roll back if remediation goes sideways.

Output as: (a) a per-resource classification table (adopt/revert/ignore + replace-risk flag), (b) the concrete code edits for adopt cases, (c) the targeted-preview verification commands, (d) a snapshot/rollback runbook. Assume production traffic depends on these resources.