bug: Add forceUnmountDisk function to handle APFS volumes on macOS

[billmcilhargey]

Fix APFS-formatted drives hanging at "Starting" on macOS

Fixes balena-io/etcher#4490.

Problem

On macOS, flashing a drive that contains an APFS volume hangs indefinitely at the "Starting" stage. Users have worked around this by reformatting the drive to ExFAT or by manually deleting the APFS volume in Disk Utility before flashing.

Root cause

When opening a BlockDevice for write, BlockDevice._open (on non-Windows) calls mountutils.unmountDisk(device) before opening the raw device with O_EXLOCK.

On macOS, mountutils.unmountDisk is implemented with DiskArbitration:

DADiskUnmount(disk,
              kDADiskUnmountOptionWhole | kDADiskUnmountOptionForce,
              callback, ctx);

It is invoked against the parent BSD device (e.g. /dev/disk2). However, APFS volumes are exposed as a separate synthesized disk (e.g. /dev/disk3) backed by an APFS container partition on the parent. The whole-disk DADiskUnmount against the parent does not propagate to the synthesized APFS volumes, so they remain mounted. The subsequent O_EXLOCK open of the raw parent device then blocks/fails — which is what users see as the indefinite "Starting" hang.

This explains the reported workarounds: reformatting to ExFAT (no APFS container) and "Delete APFS Volume…" (removes the synthesized disk) both let mountutils succeed cleanly.

Errors from diskutil are intentionally swallowed (and logged via debug):

The preceding mountutils unmount may already have handled non-APFS volumes.
If the device truly cannot be unmounted, the subsequent open() will surface a meaningful error rather than masking it.

[flowzone-app]

A repository maintainer needs to approve these workflow run(s).

To approve, maintainers can either:

• Submit an approval review on this pull request, OR

• Submit a review comment starting with /deploy

Then re-run the failed job(s) via the Checks tab above.

Reviews must be on the specific commit SHA of the workflow run to be considered.