workshop health gate blocks recovery commands (remove/stop/list) when the storage pool is full

**Environment**: workshop 0.9.4 (rev 386, latest/stable), LXD 6.9 (rev 39858), ZFS pool workshop at /var/snap/lxd/common/lxd/disks/workshop.img.

**Summary**: When the workshop ZFS pool crosses the fullness threshold (observed at 92%, 2.4 GiB free), the health check rejects every subcommand — including the ones needed to recover:
```
error: system is not healthy: storage pool "workshop" is 92% full (2.4 GiB available);
free up space or expand the pool with `lxc storage volume set workshop size=GiB`
```
`workshop remove`, `workshop stop`, and even read-only `workshop list`/`info` all abort with this before doing anything. The only way out (other than expanding the storage volume I guess) is dropping to raw `lxc delete ... --project workshop. --force`, which bypasses workshop's bookkeeping and risks orphaning shared clone-parent snapshots.

**Expected**: cleanup/recovery commands (remove, stop) and read-only commands (list, info) should be exempt from the fullness gate — or it should warn rather than hard-block for them — so a full pool is recoverable with workshop itself.

**Actual**: all subcommands hard-fail; recovery requires raw lxc.

Start with the health-check path shared by workshop remove, stop, list, and info, reproducing the full-pool condition described. Trace where the fullness gate runs and verify cleanup/recovery commands can execute while list/info can report. Done means these commands no longer hard-fail solely because the pool is full, with coverage for the exempt behavior.

Written by the indexing model from the issue text.