2.0.11-rc2: Bugfixes - #1674

Before a write, unmountVolumes() dismounted each volume on the target
disk and then called DeleteVolumeMountPointW to stop Windows from
re-mounting/re-grabbing it during the clean + raw write. Nothing ever
restored that mapping, and there is no SetVolumeMountPoint anywhere in
the tree. On card readers that Windows treats as fixed disks (RMB=0),
the Mount Manager binding is persistent, so the reader came back with no
drive letter — reinserted cards no longer appeared in Explorer and the
letter had to be reassigned by hand after every write.

Replace the letter deletion with a lock-and-hold approach that matches
what the removed mountutils dependency effectively did: lock
(FSCTL_LOCK_VOLUME) and dismount each volume, then keep the handles open
via a new LockedVolumes RAII holder for the duration of prepare (unmount
-> clean -> open). Holding the lock keeps the volume unmounted across the
critical window without touching the persistent Mount Manager binding.
Once the physical drive is open (which suppresses partition re-scan), the
locks are released; when the write finishes and the physical-drive handle
closes, Windows re-scans and reassigns the drive letter normally.

Fixes #1665.

…e mountpoints

87b62f8 opens the target physical drive without FILE_SHARE_WRITE so the OS
volume manager can't grab it mid-write. But if a transient holder (Explorer
re-scanning the just-cleaned removable disk, an AV, or the search indexer) owns
the drive at open time, the previous code dropped straight to a shared open,
which lets Windows mount the partition mid-write. Retry the exclusive open with
geometric backoff (matching Rufus's DRIVE_ACCESS wait loop) and only fall back
to shared write if exclusivity genuinely cannot be obtained.

Also stop issuing FSCTL_ALLOW_EXTENDED_DASD_IO on physical-drive handles: it is
only meaningful for volume handles and returned ERROR_INVALID_FUNCTION on a
physical drive, logging a spurious "failed" warning on every write.

Note: exclusive access reduces but does not fully eliminate the removable-reader
"insert a disk" / "format the disk" shell dialogs. Those stem from Windows
auto-managing the drive letter while the disk is partition-less mid-write and
are only fully avoidable via mount-manager AutoMount suppression, which is
deliberately not used here because of its global, crash-persistent state.

…table

When writing a customised image, DeviceWrapper::sync() wrote the FAT blocks and
then the MBR, and the raw-write path wrote the deferred first block (containing
the MBR) after the image body — but with no device-cache flush in between. On
USB card readers the bridge/card write-cache can reorder writes, so the MBR can
reach the media before the filesystem is complete. Windows then briefly sees a
partition with an incomplete filesystem and prompts to format it. This never
reproduces on a virtual disk, which has no reordering write-cache.

Flush the device cache before writing the MBR in both the customised
(DeviceWrapper::sync) and non-customised (_writeComplete) paths, so the
partition only becomes visible once its contents are durably on media, and
flush again afterwards so the MBR itself is durable.

Crash-safe: touches no global OS state. A device that does not support flush
returns success from Flush(), so this is a no-op there. This is a write-ordering
correctness fix; on its own it does not eliminate the clean-phase removable
"insert a disk" dialog.

The fastboot gadget reuses Google's USB VID/PID (18d1:4e40), so matching
VID/PID alone cannot prove a device is a Raspberry Pi. A non-Pi device in a
colliding fastboot mode (e.g. an Android phone) could otherwise be listed as
a writable target and flashed.

Add positive identification in FastbootProtocol::isRpiFastboot():
  - primary: the USB interface string descriptor the rpi-fastbootd gadget
    advertises ("fastbootd-provisioner"), read at open time via the new
    IUsbTransport::interfaceString() (overridden by LibusbTransport);
  - fallback: the RPi-specific "block-devices" getvar, which stock Android
    fastboot does not implement.

Enforce the check at discovery (drive-list poll) and again before any
destructive command in the flash thread (erase / partition / flash), so a
non-Pi 18d1:4e40 device is never enumerated or written to.

stage() has always sent the "download:" verb, not "stage:", but two tests
and the header comment assumed "stage:", leaving the fastboot suite with two
long-standing failures.

This is correct behaviour, not a bug: rpi-fastbootd maps both "download" and
"stage" to the same DownloadHandler and keeps "stage" only for backward compat
with older imagers, while its restricted TCP data-plane command map accepts
only download/flash/getvar. "download" is therefore the canonical, portable
verb and must not be changed back to "stage".

Update the two tests to expect "download:", correct the stage() documentation,
and add a note at the call site so the verb is not "fixed" back. The fastboot
test suite is now fully green.

_verify() runs before _customizeImage(), so the customisation files are the one
part of the card nothing ever reads back. A device that acknowledges writes it
never commits therefore gives a green write whose settings are simply absent on
first boot, with no indication why.

Record a digest and size for each file written, re-read them after the final
sync, and fail on a mismatch. The read uses a fresh DeviceWrapper, as the
existing block cache does not evict on sync() and would otherwise compare our
own buffer against itself, and re-asserts direct I/O to bypass the page cache.
The device's own cache cannot be defeated, so this yields false passes but never
false failures; hence failing hard on a mismatch is safe.

boot.img is content-checked only when verification is enabled, size always.
Hashing goes through AcceleratedCryptographicHash, as the rest of the write path
does. Reported as a new customisation_verify event.

This also catches the swallowed writeFile() failure at the end of
_createSecureBootFiles(), which needs no faulty hardware.

Not yet exercised on real media.