v0.21.0: volumes — ZFS datasets, btrfs subvolumes, XFS/ext4 project quotas, as shares

fileshare can now CREATE the storage a share serves, sized and tracked, through its admin gRPC API — and does it without becoming privileged itself (design: docs/volumes.md).

Two roles of one binary

• fileshare provisioner (new, #59): a small privileged process (CAP_SYS_ADMIN, plus CAP_CHOWN/CAP_FOWNER) behind a unix socket, speaking a closed protocol (fileshare.provision.v1): GetCapabilities, CreateVolume, ResizeVolume, SnapshotVolume, DeleteVolume, GetVolume, ListVolumes. Only the configured uid is answered (SO_PEERCRED, checked before anything is decoded); an unknown method or a malformed message closes the connection. A request never carries a path — a parent id from the provisioner's own configuration and a name matched by a strict grammar. Every volume carries an ownership mark (ZFS: a fileshare:volume property set ON the dataset, not inherited; btrfs: subvolume id and uuid in its state; XFS/ext4: a project id from a configured range), checked before any resize, snapshot or delete. Create and delete are idempotent by name.
• fileshare serve (#60) stays unprivileged and relays: the admin API gains ListParents, CreateVolume, ResizeVolume, SnapshotVolume, DeleteVolume, GetVolume, ListVolumes, and CreateShare accepts volume { parent, name } as a source. Before serving one it checks the path is under source_roots, a directory, on the expected filesystem (and a ZFS mount, a btrfs subvolume root, an XFS/ext4 directory with a project id).

Backends (go-fsctl v0.1.0, pure Go, no CLI): ZFS datasets with refquota, btrfs subvolumes with qgroup limits, XFS and ext4 directories with project quotas (new go-fsctl/projquota). Ceph is not supported yet.

Measured in CI as root on real pools and loop filesystems, with fileshare serve running as nobody and driven through the admin API: writes over WebDAV and SFTP stop at a 32 MiB volume's quota on all four kinds.

⛔ ext4 lets CAP_SYS_RESOURCE (root) write past a project quota, so fileshare serve refuses to serve volumes when it runs as root or holds CAP_SYS_RESOURCE in its effective or permitted set.

Also: ENOSPC and EDQUOT now give the same "full" answer (WebDAV 507, NFS NOSPC, SFTP "no space left"); SMB still answers access denied, pending go-filesystems/smb. The admin socket accepts an optional allowed_uids.