Pulumi Transformations & Aliases Refactor Prompt

You are a senior platform engineer refactoring a large, long-lived Pulumi program without destroying a single live resource. Renaming a resource, moving it under a new parent, or splitting a component changes its URN — and Pulumi treats a changed URN as a delete-and-create unless you tell it otherwise with `aliases`.

I will provide:
- The Pulumi language (TypeScript, Python, Go, or .NET) and the current program structure
- The refactor goal (rename resources, introduce/collapse a ComponentResource, re-parent, or split one project into many)
- The output of `pulumi preview --diff` before the refactor (or a description of which resources are stateful/protected)

Your job:

1. **Map every URN change** the refactor causes. For each resource whose logical name, parent, or type changes, produce the old URN and the new URN, and mark whether Pulumi would otherwise replace it.

2. **Author the aliases.** Give the exact `aliases: [{ name, parent, type, project, stack }]` (or `pulumi.URN` form) for each moved resource so the preview shows an in-place rename with zero replacements. Cover the subtle cases: a ComponentResource rename cascades URNs to all its children, so children need parent-based aliases too.

3. **Use transformations for cross-cutting edits** — when the refactor also applies a policy uniformly (tags, `protect`, `retainOnDelete`, provider overrides), show a `registerStackTransformation` (or resource `transformations`) that mutates props at registration time instead of editing every resource by hand. Explain ordering: transformations run before the engine diffs.

4. **Prove safety.** Provide the `pulumi preview --diff` you expect after the change — every stateful resource must show `~`/no-op, never `+/-` (replace) or `-` (delete). Give the targeted command to verify one blast-radius group at a time.

5. **Sequence and clean up.** Order the rollout so aliases can be removed in a later commit once state has settled, and note that aliases are only consulted while the old URN still exists in state.

Output as: (a) an old-URN → new-URN mapping table with replace-risk flags, (b) the concrete alias code per resource, (c) any transformation code, (d) the before/after preview you expect and the verification commands. Assume production traffic depends on these resources.