Shared directories should work without the user installing or configuring anything

### Request

Adding a shared directory should work the way it does in VirtualBox: you pick a host folder and it appears in the guest — writable or read-only if desired, owned by the guest user, still there after reboot — with no further user action and no need to understand how it works. Today UTM requires guest-side research and manual setup: finding the mount tag, writing an `/etc/fstab` entry, and knowing which guest packages (if any) are required.

UTM appears to already do this for one combination: #5571 added automatic shared-directory mounting for macOS guests on the Apple Virtualization backend. This asks for the same outcome for Linux guests on QEMU — extending existing behaviour rather than introducing a new concept.

### Why it doesn't work today

The Sharing pane tells every guest:

> Requires SPICE guest agent tools to be installed.
> WebDAV requires installing SPICE daemon. VirtFS requires installing device drivers.


**The driver warning is wrong in the common case and useless in the rare one.** Mainstream distro kernels already ship the 9p modules and autoload them:

```
$ grep -E '^CONFIG_(9P_FS|NET_9P|NET_9P_VIRTIO)=' /boot/config-$(uname -r)
CONFIG_NET_9P=m
CONFIG_NET_9P_VIRTIO=m
CONFIG_9P_FS=m
```

They are modules, not built-ins, so a minimal or custom kernel genuinely can lack them (Alpine needs the virt flavour), but the notice alarms users who need nothing, and tells the few who need something neither what exactly they need or how to check for it:

**The "SPICE guest agent tools" are never specifically named.** For Linux they are `spice-vdagent` and `spice-webdavd`, from the distro's own package manager.

**There is also a menu item that sounds like it could be an answer, but it is Windows-only.** *Virtual Machine ▸
Drives ▸ Install Guest Tools…* mounts an ISO containing a Windows `.exe`. A Linux user who finds it (as in #5875) doesn't get anything usable.

### Mounting is only half the issue

A Linux guest-tools installer alone would not close this. VirtualBox works end to end because Guest Additions installs `vboxsf` **and** `vboxsf` accepts `uid=`/`gid=`, so files arrive owned by the guest user regardless of the host's uids.

9p has no equivalent remapping option, and #4458 has collected reports since 2022 of shares that mount but are not writable, with a user-installed `bindfs` layer as the standing answer. To be clear about what I did and did not see: I could not reproduce that on UTM 4.7.5 — a plain `access=client` mount read and wrote fine, host uid 501 against guest uid 1000, no `bindfs`. So this may already be in better shape than that thread suggests. Either way, "it mounts" and "it is usable" are separate outcomes, and only the second is what this request is asking for.

Environment: UTM 4.7.5 (118) on macOS 26.6.1 (Tahoe), Apple silicon.
Guest: Ubuntu 26.04 LTS, kernel `7.0.0-29-generic`. Directory Share Mode = VirtFS.

Start by comparing the automatic shared-directory mounting added for macOS guests on the Apple Virtualization backend in #5571 with the Linux guest flow for QEMU VirtFS/9p. Trace how the Sharing pane, guest tools, mount behavior, and ownership are handled. Done means a Linux guest can use a selected share after reboot without manual fstab, package, or bindfs setup, with writable or read-only access as selected.

Written by the indexing model from the issue text.