ocpvirt-provisionlisted

# ocpvirt-provision Phase 3. Runs `terraform/ocpvirt/` and registers the resulting VMs in AAP so the demo content has hosts to run against. This skill contains **no logic**. All the work is in [`playbooks/provision_vm.yml`](../../../playbooks/provision_vm.yml), which is the same playbook the `Linux Day 1 - 1 Provision` job template runs, with survey answers mapped to the same variable names. See `CLAUDE.md` → *Skills and playbooks*. **Prefer the job template when AAP is available** — it is the demo-able path and the one a customer sees. This skill is for when you are working ahead of AAP, or debugging a run without the controller in the way. ## The inputs are the contract | Variable | Values | Default | |---|---|---| | `vm_size_tier` | `small`, `medium`, `large` | `small` | | `os_type` | `linux`, `windows`, `both` | `linux` | | `vm_role` | `web`, `db`, `app` (1-8 lowercase alphanumeric) | `web` | | `vm_count` | `1` or `2` | `1` | These names are shared verbatim with the AAP survey and `terraform/ocpvirt/variables.tf`. Changing one means changing all three. **`vm_role` and `vm_count` build a farm (#389).** VMs are named `{role}-{os}-{index}` — `web-win-1`, `db-lnx-2` — and `vm_count=1` behaves exactly as a single-VM run always did. Two things follow that are easy to get wrong: - **Each role has its OWN Terraform state** (`secret_suffix=<env>-<os>-<role>`), the same way each OS has since #301. So `vm_role=db` cannot disturb a running `web` farm — and **a teardown mu