fix: gracefully handle missing board_name DMI file

[beyondbrokkoli]

Fix Calamares crash in QEMU/Proxmox VMs caused by missing board_name

Crash Log Reference: https://paste.cachyos.org/p/6c1fa8e.log

The Issue & Cause:
When installing CachyOS inside a default Proxmox/QEMU virtual machine, the Calamares installer currently suffers a fatal crash during the chwd phase.

By default, QEMU/Proxmox does not provide SMBIOS Type 2 (Baseboard) data to the guest OS, meaning the Linux kernel never generates the /sys/devices/virtual/dmi/id/board_name file. A recent commit adding board_name_pattern support uses .expect() when reading this file, which immediately panics and kills the installer if the file is missing.

The Debugging and Testing Process:
To ensure this fix is robust and behaves exactly as expected in a live environment, I ran through a complete verification session:

1. The Workaround (Isolating the Bug):
   I originally bypassed the Calamares crash by editing my Proxmox VM configuration and manually injecting a fake motherboard via args: -smbios type=2,manufacturer=Proxmox,product=ProxmoxVM. Because I have installed CachyOS in VMs many times and never needed this workaround, it isolated the missing baseboard file as the exact point of regression.
2. Replicating Calamares (The Crash Test):
   To test the unpatched code locally, I booted a Live ISO (with 16GB RAM to handle package syncing), removed the SMBIOS workaround from the VM, and cloned the repo. To perfectly replicate how calamares/modules/chwd/main.py executes the hardware detection inside the chroot, I built the code and ran:

cargo build --release
sudo ./target/release/chwd --autoconfigure

This successfully replicated the exact .expect() panic seen during the GUI installation.

3. Verifying the Patch (The Success Test):
   I applied this patch, which simply replaces .expect() with an if let Ok(...) block. I rebuilt the binary and ran the exact same --autoconfigure command. The patched tool safely caught the missing file, assumed the hardware didn't match the profile, returned an empty vector, and successfully completed the hardware configuration without panicking.

Transparency Note:
While I tracked down the hypervisor regression, isolated the bug, and structured the testing methodology through VM debugging, I do not write Rust natively. I relied on an LLM (Gemini) to help me draft the safe Rust syntax for the fix. The logic makes complete sense for the VM use-case, but I wanted to be fully transparent about how the code was generated. Let me know if any adjustments are needed!