RFC: IaC strategy — Pulumi integration vs first-party IaC primitive

Part of the **Continuous Delivery Vision** ([#8](https://github.com/ChrisonSimtian/Fallout/milestone/8)). The strategic fork for the **infrastructure-as-code** pillar identified in the taxonomy RFC (#285).

## The fork

For the IaC side of CD, two broad directions:

### A) Pulumi integration
Lean on **Pulumi** (already C#-native, multi-cloud, mature provider ecosystem) and give Fallout a clean integration surface. Users who want IaC bring Pulumi; Fallout orchestrates it.
- ➕ Massive provider coverage for free; no reinventing cloud APIs.
- ➕ Lowest maintenance; users can already do this themselves today.
- ➖ External dependency + runtime; another tool/state backend in the chain.
- ➖ Less "code-first Fallout-native" feel.

### B) First-party IaC primitive ("be cheeky and write our own")
A Fallout-native declare/plan/apply primitive (cf. #249 Fallout.Reconcile), with provider adapters tested against the emulators (Topaz/LocalStack/GCP emulators) and Proxmox.
- ➕ Fully code-first, single tool, consistent with Fallout's C#-native ethos.
- ➕ Tight fit with our plan/apply + CD primitives.
- ➖ Enormous surface to build and maintain (cloud APIs, drift, state).
- ➖ Competing with Pulumi/Terraform on their home turf.

## Probably not binary

A middle path exists: ship the integration (A) as the pragmatic near-term answer **and** build a narrow first-party primitive (B) for the targets where we control the emulator cheaply (Proxmox/on-prem first?). This RFC is where we decide the sequencing.

## Open questions

- Near-term: integration first, own-primitive later — or commit to one?
- If own: does it build on #249 Fallout.Reconcile as the plan/apply core?
- Scope of a v1 first-party primitive — which provider/targets, how narrow?

Design issue — no implementation commitment.