ide: audit enlightened INT13 command set and consider restricting to BIOS-issued commands

The enlightened INT13 HDD path (enlightened_hdd_command) currently accepts any IdeCommand value from the guest-provided EnlightenedInt13Command.command field without validation.

Two questions worth investigating:

1. What commands does the Hyper-V synthetic BIOS actually send via the enlightened INT13 port? This requires access to the BIOS firmware source to determine the exact command set.

2. Should we restrict the enlightened path to only accept commands the BIOS is known to issue? Adding an allowlist would make the contract explicit and prevent silent misbehavior for unexpected commands — a defense-in-depth improvement.

Context: This came up during review of #3062 (adding WRITE_DMA_FUA_EXT to the 48-bit LBA setup). The fix in #3062 is a consistency fix between the enlightened register setup and handle_command(), but the broader question of which commands the BIOS actually sends — and whether we should enforce that — is worth tracking separately.

Related:

• #3062 — WRITE_DMA_FUA_EXT 48-bit LBA setup fix
• #3040 — non-DMA command rejection (DMA allowlist for the enlightened path)
• #3061 — original issue for the FUA_EXT bug

Start by obtaining the Hyper-V synthetic BIOS source to identify commands sent through the enlightened INT13 port. Then inspect enlightened_hdd_command, EnlightenedInt13Command.command, and handle_command(), using #3040 and #3062 for context. Done means documenting the BIOS command set and deciding whether an explicit allowlist is warranted.