### System details

Omarchy Quattro

### What's wrong?

### Description
Enabling the "Direct Boot" feature in Omarchy results in a complete hardware brick on specific older Dell laptop models. After enabling the feature and rebooting, the machines fail to POST, resulting in a black screen, brief fan spin, and an automatic shutdown. The BIOS becomes entirely inaccessible and software-based BIOS recovery fails, requiring physical SPI hardware flashing to revive the motherboards.

### Hardware / Environment
*   **Machine 1:** DELL XPS 15 9550
*   **Machine 2:** DELL Precision 5510
*   **OS:** Omarchy Linux

### Steps to Reproduce
1. Install and run Omarchy normally (works fine with Limine).
2. Enable "Direct Boot" in the OS.
3. Reboot or shut down the machine.
4. Attempt to power on the machine.

### Symptoms & Behavior
*   Pressing the power button lights up the LED, the screen remains entirely black (no Dell logo, no backlight), fans spin up for a few seconds, and the machine shuts down.
*   **Diagnostic LED Code:** If the NVMe SSD is removed, the Dell diagnostic LED flashes `3,3` (3 amber, 3 white), which translates to "BIOS recovery image not found". 
*   If the SSD is inserted, the machine simply crashes and shuts down before any LED code is displayed.

### Troubleshooting Attempted (Failed)
Extensive troubleshooting was performed to rule out standard hardware failures:
*   Removed CMOS battery to reset volatile NVRAM.
*   Tested bare-metal boot (1 RAM stick, no SSD, battery disconnected).
*   Attempted Dell's built-in BIOS Recovery (`CTRL + ESC` on AC power connection) using a 2GB FAT32/MBR formatted USB drive with correctly named recovery files (`BIOS_IMG.rcv` / extracted `.hdr`). 
*   **Result of Recovery:** The machine detects the USB (the `3,3` error code disappears), but the BIOS parser hangs indefinitely on a black screen. The CPU heats up, indicating it is stuck in an infinite POST-loop attempting to parse the recovery file but failing.

### Technical Hypothesis
The issue does not seem to be a standard OS crash, but a severe incompatibility between Omarchy's Direct Boot implementation and Dell's notoriously fragile UEFI firmware from this era. 

When Direct Boot writes a custom EFI boot entry pointing directly to the Omarchy UKI via `/sys/firmware/efi/efivars/`, it writes a variable that the Dell firmware parser cannot handle. 

Upon the next boot, during the very early POST phase (before display initialization), the Dell firmware attempts to read this corrupted/unsupported NVRAM variable. The parser hits a fatal exception and crashes the system. Because this specific EFI variable is stored persistently on the flash chip (and survives a standard CMOS battery removal), the motherboard is permanently stuck in a pre-POST crash loop. The parser is too corrupted to even execute the built-in USB BIOS recovery tool.

### Suggested Action
Given the severity (hard brick requiring an EEPROM programmer / CH341A to fix), I recommend adding a strict warning in the documentation or implementing a hardware blacklist preventing Direct Boot from being enabled on Dell XPS/Precision models from the 9550/9560/5510 generations.