Make an app's storage attachments declarable as a set

Description of feature

dokku_storage_mount describes one attachment. It takes an app, a container dir, and the mount-time fields, and its present and absent states add or remove that single attachment. There is no way to say "these are the only mounts this app should have", so a mount attached out of band, or one dropped from a recipe, is never removed.

dokku/dokku#8991 asks for a whole-set form for an app's storage attachments, since storage:mount is a per-attachment upsert and storage:unmount a per-attachment remove, with no trigger that rewrites the set. Once that lands, docket can express the full set in one task.

The shape question is ours to answer regardless of what upstream ships. An authoritative set does not fit dokku_storage_mount as it stands, because that task is keyed on a single attachment - it would need either a new task type describing the whole list, or a state on the existing task whose body means something different from the per-attachment case. The first is probably cleaner and matches how dokku_domains handles the same tension, but it means two task types covering one plugin, which is worth weighing.

An interim without upstream is to diff storage:list <app> --format json and issue one mount or unmount per difference. For storage that non-atomicity is worse than usual: a failure partway through leaves an app that may mount the wrong volumes on its next start, so this is a stopgap I would rather not ship.

Blocked on dokku/dokku#8991.

Start by reading the dokku_storage_mount task and comparing its single-attachment behavior with dokku_domains. Review dokku/dokku#8991 and the storage:list, storage:mount, and storage:unmount entry points; done means choosing and implementing a whole-set task shape without relying on the non-atomic diff stopgap.