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;

docs/file-system-development/storage-design-rationale.md

@@ -251,8 +251,9 @@ matrix-proven shape; genuinely open.
    whether USB port, hub depth, SATA port, or a stick that left as USB and
    returned in a SATA dock; **replug remounts at the same path** (the id-path is
    content-derived, so a volume returns to `/volumes/<id>` wherever it reappears;
-   remount-on-replug end-to-end is bench-verified, not QEMU-tested, because QEMU
+   the re-adopt+remount code path is QEMU-proven by the driver-crash rebuild, but
-   can't re-present the boot-controller device); **the boot volume** is the volume
+   remount on a *physical* replug end-to-end is bench-pending, not QEMU-testable,
+   because QEMU can't re-present the boot-controller device); **the boot volume** is the volume
    that resolves `/system/configuration` on its own media, findable on any port or
    partition; and **duplicate identity is a known S4 gap** — two cloned sticks
    share one content id, so today they collide on `/volumes/<id>` (the kernel