Registry only tracks one mount per volume; concurrent mounts of the same volume get orphaned #16

Summary

smolfs tracks mount state as a single mountpoint + read_only pair per volume record ($SMOLFS_HOME/volumes/NAME.toml). This means a single registry cannot represent more than one concurrent mount of the same named volume. JuiceFS itself supports concurrent mounts of the same volume (including one read-only and one read-write) just fine — so smolfs's bookkeeping is the limiting factor, and it fails silently in ways that can leave orphaned mounts.

This surfaced while implementing read-only mounts (#14 / #15), but it is a pre-existing limitation independent of that feature.

Reproduction

Two smolfs invocations (separate processes), same SMOLFS_HOME, same --dev volume:

smolfs init demo --dev
smolfs mount --readonly demo /tmp/ro   # process 1
smolfs mount demo /tmp/rw              # process 2 (same volume)

Observed:

• Both mounts physically succeed — mount shows both JuiceFS:demo on …/ro and …/rw. The read-only one correctly rejects writes (read-only file system); the read-write one accepts them; files written via /rw are visible via /ro (same filesystem, independent access modes). This works even for a dev/SQLite volume on one machine.
• mount() has no guard against an already-mounted volume — the second mount overwrites mountpoint/read_only in the one record. smolfs status demo then shows only the last mount (…/rw rw); the read-only mount is no longer tracked.
• smolfs unmount demo unmounts only the recorded (last) mountpoint — the first mount is left orphaned: still mounted at the OS level, but status reports the volume as unmounted (- -). It has to be umounted manually.

Impact

• Silent loss of tracking when the same volume name is mounted more than once in a registry.
• Orphaned mounts that smolfs no longer knows about and won't clean up.
• flush/unmount/status NAME are ambiguous when more than one mount exists.

Possible direction

Model multiple concurrent mounts per volume rather than a single mountpoint:

• Store a list of mounts (e.g. Vec<MountRecord>), each with its own mountpoint and read_only.
• Have flush / unmount take (or disambiguate by) a mountpoint, and error clearly when the target is ambiguous.
• Optionally, mount could warn/refuse when the exact mountpoint is already recorded, and status could list all live mounts with their modes.

Notes

• Relevant code: SmolFs::mount / flush / unmount and the Volume record in crates/smolfs-juicefs/src/service.rs and crates/smolfs-core/src/models.rs.
• Cross-machine concurrent access already works for cloud volumes because each client has its own SMOLFS_HOME/registry; this issue is specifically about multiple mounts sharing one registry.