ide: include WRITE_DMA_FUA_EXT in enlightened 48-bit LBA setup

[juantian8seattle]

The enlightened HDD path in enlightened_hdd_command() programs high LBA/sector-count registers only for READ_DMA_EXT and WRITE_DMA_EXT. WRITE_DMA_FUA_EXT (0x3D) is also a 48-bit command but was missing from the check, so its high LBA bytes would not be written to the drive registers -- the drive would use stale values.

Add WRITE_DMA_FUA_EXT to the 48-bit LBA branch condition.

Fixes #3061

[Copilot]

Pull request overview

This PR fixes a correctness issue in the IDE enlightened INT13 HDD path by ensuring 48-bit LBA register programming also occurs for WRITE_DMA_FUA_EXT, preventing stale high-LBA / sector-count register values from being used during that command.

Changes:

• Extend the 48-bit LBA command check in enlightened_hdd_command() to include WRITE_DMA_FUA_EXT.

---

You can also share your feedback on Copilot code review. Take the survey.

[jstarks]

Our BIOS never sends this command, does it?

[jstarks]

see comment

[juantian8seattle]

handle_command in hard_drive.rs already accepts FUA_EXT as a 48-bit DMA command (use_48bit_lba: true), and the enlightened path dispatches through it after setting up registers. So if FUA_EXT comes in via the enlightened port, handle_command reads the 48-bit register FIFOs -- but the enlightened path never wrote the high bytes into them. The drive gets stale register values.

This just makes the enlightened register setup consistent with what handle_command already expects.