RFC: CD scope taxonomy — application deployment vs infrastructure-as-code

Part of the **Continuous Delivery Vision** ([#8](https://github.com/ChrisonSimtian/Fallout/milestone/8)) — cross-cutting framing for all the provider tracks (Azure #281, AWS #282, GCP #283, Proxmox/on-prem #284).

## The two sides of CD

All the provider work splits into two distinct pillars, and we should be deliberate about treating them separately:

1. **Application deployment** — getting a built artifact running on a target (push image/binary, roll out a service, run a container/LXC, deploy to a VM).
2. **Infrastructure as code** — declaring and reconciling the target infrastructure itself (resource groups, networks, storage, VMs, clusters) before/around the app deploy.

## Why this matters

- The primitives, failure modes, and idempotency stories differ sharply between the two.
- A provider track (Azure/AWS/GCP/Proxmox) generally needs **both**, but they can ship independently and be designed against different abstractions.
- The IaC pillar has its own strategic fork — see the companion RFC #286 (Pulumi integration vs. first-party primitive).

## Open questions

- Do app-deploy and IaC share a common plan/apply core (cf. #249 Fallout.Reconcile), or stay separate?
- Where does the provider boundary live — one abstraction with provider adapters, or per-provider primitives?
- How much of this is first-party vs. left to existing tools?

Scoping/design issue — no implementation commitment.