nvme_driver: add timeout to controller ready/reset wait loops

Summary

The NVMe driver's enable() and reset() functions poll CSTS.RDY in infinite loops using Backoff, with no upper bound on iterations. If the controller never reaches the expected state, the driver hangs forever.

Affected code

• driver.rs enable() loop — waits for CSTS.RDY after setting CC.EN=1
• registers.rs reset() loop — waits for CSTS.RDY=0 after setting CC.EN=0

Both use Backoff::new(driver) which yields 250 times, then sleeps 1ms × 250, then 15ms forever — never giving up.

NVMe spec reference

NVMe spec section 3.5.2 defines CAP.TO (offset 0x00, bits 31:24) as the maximum time the host should wait for CSTS.RDY to change after CC.EN transitions, in 500ms units. The driver should read CAP.TO and bail after that duration.

Impact

• Fuzzing: the NVMe driver fuzzer (fuzz_nvme_driver) cannot fuzz setup-time parameters (nsid, bounce_buffer, msix_count) because the fuzzed emulated device may return CSTS values that prevent the controller from reaching ready state, causing the fuzzer to hang.
• Production: a misbehaving physical device or malicious VF could hang the driver thread forever.

Suggested fix

Add a max iteration count or deadline to both loops, based on CAP.TO. Bail with an error if the timeout expires.

Read the enable() loop in vm/devices/storage/disk_nvme/nvme_driver/src/driver.rs and the reset() loop in registers.rs, then inspect how Backoff and CAP.TO are represented. Done means both loops stop waiting and return an error after the CAP.TO-based timeout, including when CSTS.RDY never reaches the expected state.