Reduce risk of surprise bulk writes during disk import

In https://github.com/oxidecomputer/omicron/pull/10046#issuecomment-4050549889 I had GPT-5.4 make the case against excluding disk_bulk_write_import from the audit log, and it came up with a pretty good reason: you could create a disk, put it in import mode, write a bunch of blocks to it, finalize it, snapshot it, make it into an image. If during that time, some other use wrote a block to your disk, you would never know it, especially if we're not tracking those writes in the audit log.

I don't think that argument is strong enough to throw out the change and have 90% of our audit log writes be bulk write calls, but it is probably worth mitigating some of the risk. Some possible mitigations:

• Lock down writes to the user that put the disk in import mode
  • We don't do user-specific auth anywhere else that I'm aware of, but it's a cool idea. All we'd have to do is write down the user ID in the disk status and reject writes from any user that didn't match it.
• Give the user a way to get a hash of the disk or image that they can verify against their source file
  • Complicated by the fact that a disk with extra empty space in it might look different from the original file, but there are ways to work around that. We are doing related work around attestation that we may be able to repurpose here.

Start by reading the discussion in PR 10046, especially the linked issue comment, and trace the existing disk_bulk_write_import and audit-log behavior. The issue presents multiple possible mitigations rather than a selected change; done would require agreeing on one approach and defining how it prevents or exposes unexpected writes during import.