Mounted disks writable by the service's run user by default

A Miren disk mounts as root:root, but plenty of real-world container images run as a non-root user, so the app can't write to the disk it just asked for. Today the only way through is to chown the mount from inside the image's entrypoint — and since Miren runs the service command in place of the image's entrypoint, that means shipping a wrapper script whose whole job is chown -R appuser /data && exec …. A recent deploy of Chatto (whose official image drops to an unprivileged user) needed exactly that shim before it could write its database. This is the intent of the canceled MIR-621, rescoped into Production Ready Disks where it belongs: MIR-1318 frames the goal as "get disks to a point we're comfortable with customers relying on," and "the app can write the disk it mounted" is table stakes for that.

Proposed behavior:

• Writable by default. A mounted disk is owned by the service's run user (uid/gid taken from the image's configured User, overridable). For an image that runs as root this is a no-op, so nothing regresses.
• Ownership, not permission width. This is chown to the one user that needs it, not chmod 0777. It composes with — and does not undo — MIR-462's tightening of mount mode bits. Keep the modes tight; just fix ownership.
• Cheap chown, not a boot-time trap. Chown on first provision (empty disk), and otherwise only when the top-level dir's ownership doesn't already match — the fsGroupChangePolicy: OnRootMismatch pattern Kubernetes landed after hitting exactly this. Never a blind chown -R every mount; on a large disk that's a slow-boot surprise.
• Override for the unusual case. A field to pin or opt out (owner = "keep", or a specific uid) for the rare app that genuinely wants raw mount ownership.

Context and references: MIR-621 (canceled predecessor), MIR-462 (mount permission width — the orthogonal axis), RFD-91 "Bring Your Own Image" (the narrative this fits into — bringing an upstream image should Just Work, and a writable disk is half of that). Implementation touches the mount setup in controllers/sandbox/sandbox.go.

Open question: derive the run-user uid from the image config, or require it explicitly via the user service field proposed in RFD-91? Probably derive-with-override, but worth settling.