Feature request: declarative LUKS2/Btrfs root installation in headless mode

Hi,

This is a feature request for the JSON/headless installation interface: **support for declaring and provisioning a LUKS2-encrypted Btrfs root**.

I’m exploring repeatable provisioning of personal CachyOS workstations, including replacement hardware. I’d like to retain CachyOS’s installation policies and improvements rather than maintain a separate installation implementation.

### Use case

The intended workflow would:

1. Boot CachyOS installation media.
2. Identify the target disk and explicitly authorize erasure.
3. Install from a declared storage and desktop configuration.
4. Apply workstation-specific configuration and restore selected data.
5. Verify the resulting system.

Credentials can be supplied at startup; installation should then proceed without interactive prompts.

The storage layout I need is relatively conventional:

- UEFI/GPT.
- An unencrypted ESP, with configurable size.
- LUKS2-encrypted Btrfs root.
- Standard CachyOS subvolumes plus additional snapshot-exclusion subvolumes.
- Limine and an appropriate encrypted-root initramfs.

Persistent swap for hibernation would live inside the encrypted filesystem. YubiKey enrollment and personal configuration can remain separate post-install steps.

### Headless interface limitation

Looking at current head (bb3eccb):

- Headless configuration does not expose root-LUKS provisioning.
- [headless_strategy_from_config](https://github.com/CachyOS/New-Cli-Installer/blob/bb3eccb03e85007ba5db65a952f82af132b0e21d/installer-lib/src/headless_plan.cpp#L158) selects `CreateLayout` or `EraseAndAuto`.
- Those paths recreate the partition table and format the configured filesystems.
- An internal `UseExisting` strategy and LUKS format/open primitives exist, but headless configuration does not expose a route combining them for this use case.

Consequently, preparing encrypted storage externally and then invoking the normal headless layout path would not be a safe workaround.

### Questions

- Would you be open to accepting a contribution adding declarative LUKS2/Btrfs root provisioning to the headless installer?
- Would native root-encryption configuration be the preferred approach, or an explicitly validated existing-target mode?
- For equivalent installation choices, should consumers expect Calamares-compatible defaults, or treat the CLI’s policy as independent?

Thanks!

Start with installer-lib/src/headless_plan.cpp at headless_strategy_from_config and trace the CreateLayout, EraseAndAuto, and internal UseExisting paths. Clarify whether the contribution should expose native declarative LUKS2 provisioning or a validated existing-target mode, along with the expected policy defaults. Done means the chosen headless workflow safely provisions the requested encrypted Btrfs root without interactive prompts.

Written by the indexing model from the issue text.