feat: verify drive at startup, make UMS prep cancellable

[teal-bauer]

Summary

• Drive is verified (fsck + size) at service startup, not lazily on first UMS entry
• Virtual drive created as a sparse file via os.Truncate; 1GB creation drops from ~10s to ~1s (2.1MB physical on eMMC)
• UMS prep is cancellable: a mode=normal request mid-prep cancels the in-flight op, flips {status,step} to idle immediately, and unwinds in the background
• Left-brake-hold now works during prep, not just during active UMS

Background

Two shortcomings made UMS switching feel unresponsive:

1. diskMgr.Initialize only checked whether the file existed. fsck.fat was deferred to Mount(), so the first UMS entry after corruption blocked the user behind a full drive recreation. And that recreation was a dd if=/dev/zero bs=1M count=1024, which takes >30 seconds on eMMC.
2. handleModeChange held s.mu across the entire prep. A mode=normal request mid-prep queued behind mount, settings copy, diagnostics collection (journalctl 8h + 30s DBC SSH), and unmount. scootui kept showing "preparing storage" for tens of seconds after the user asked to exit.

Changes

pkg/disk/manager.go

• Initialize runs new verifyOrRecreate: fsck on existing, recreate if missing, smaller than configured, or fsck fails. Larger-than-configured file is kept (don't destroy user data on size decrease).
• createDriveFile uses os.Truncate for sparse allocation. mkfs.fat writes FAT metadata only, rest stays sparse.
• Mount no longer runs fsck.
• Mount/Unmount/CleanDrive take context.Context; subprocess calls use exec.CommandContext. Unmount intentionally ignores its context because a stale loopback mount blocks the next session.

Service lifecycle (internal/service/service.go)

• New operation { target, ctx, cancel, done } type and single requestMode(target) dispatcher. All three callers (hash watcher, detach loop, brake-hold) route through it.
• dispatchMu serializes transitions. s.mu is only held for short state updates, not across I/O.
• Cancelling an in-flight op: cur.cancel() + publishIdle() via SetMany({status:idle, step:""}) + wait on cur.done.
• UMS prep checks op.ctx.Err() between each step; on cancel, deferred teardown unmounts using context.Background().
• Post-UMS processing runs under context.Background(). A Mender install mid-cancel is unsafe, so that phase is not cancellable by design.
• Seeded currentOp as a stable normal state at startup so dispatcher logic has a defined starting point.

Context propagation

• settings.{CopyToUSB, CopyFromUSB}
• update.PrepareUSB
• maps.PrepareUSB
• wireguard.{PrepareUSB, CopyToUSB, SyncFromUSB}
• diagnostics.CollectToUSB (biggest win: SSH to DBC and journalctl now get SIGKILL on cancel)
• rpm.PrepareUSB, scripts.PrepareUSB

internal/service/brake_exit.go

• Checks s.currentOp.target instead of usbCtrl.GetCurrentMode(), so exit works during prep.

Test plan

Tested on deep-blue:

• Cold start with drive file deleted: service started + recreated drive in ~1s (vs. ~10s on main). File is 1.0G apparent, 2.1M physical.
• Cold start with existing healthy drive: startup unchanged, no spurious recreation.
• redis-cli HSET usb mode ums during prep, then HSET usb mode normal mid-diagnostics: status flips to idle immediately, background teardown completes cleanly, next UMS request succeeds.
• Same but with left-brake-hold triggering the exit during prep.
• ums-by-dbc two-disconnect flow still works.
• Full round-trip with updates + wireguard changes on the drive, verify processing phase completes uninterrupted.