docs: storage remount-on-replug is bench-pending, not bench-verified

The physical unplug/replug remount was never actually bench-run — the claim was
carried over from S3. QEMU cannot re-present a usb-storage device_add, so this
path is only reachable on real hardware. Correct both docs to say bench-pending,
keeping the honest distinction: the re-adopt+remount CODE PATH is QEMU-proven by
the driver-crash rebuild; only the physical-replug end-to-end awaits a bench pass.

docs/file-system-development/storage-architecture.md

@@ -28,7 +28,7 @@
 > crashes while its device stays present (a channel-liveness `geometry()` probe
 > reaps the volume and rebuilds it on the restarted driver's fresh channel). The
 > re-adopt-and-remount path is QEMU-proven by the driver-crash rebuild; a physical
-> unplug/replug exercises the same path and is bench-verified (QEMU cannot
+> unplug/replug exercises the same path but is bench-pending (QEMU cannot
 > re-present a usb-storage `device_add`). **Still pending**: the `filesystem UUID`
 > rung (ext-family superblocks, which need such an engine); and arbitration when
 > two volumes both resolve the boot markers (S3 mounts both and logs each claim;