docs: the second engine is built — exFAT + proven harness reuse (S4)

Flip the storage docs to record exFAT as a built second engine reusing
the shared filesystem harness wholesale (the reuse the architecture
promised): full read + write, directories, rename, on-disk up-case
folding, routed by VBR to fat or exfat at an exfat-<serial> id-path.
Note the two surface limits shared by BOTH engines as vfs-layer concerns,
not exFAT shortcuts: u32 file offsets (a 4 GiB cap) and ASCII-only names.

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

@@ -18,8 +18,13 @@
 > its own `/volumes/<id>` path with its own supervision. The boot volume is
 > identified by **content** (a volume backs `/system/configuration` + `/system/logs`
 > only when it resolves `/system/configuration` on its own media), so it works as
-> any partition of any device. **Still pending**: the `filesystem UUID` rung and
-> a second engine (exFAT, S4); the volume manager *consuming* `medium_changed`
+> any partition of any device. exFAT is **built** as a second engine
+> (`system/services/exfat`): full read + write, directories, rename, and on-disk
+> up-case folding, reusing `library/kernel/file-system-harness` wholesale — the
+> reuse claim, proven — and a volume routes to fat or exfat by its VBR, at an
+> `exfat-<serial>` id-path. **Still pending**: the `filesystem UUID` rung (ext-
+> family superblocks, which need such an engine); the volume manager *consuming*
+> `medium_changed`
 > (removal is detected by device-presence polling; the event is published but only
 > a card-reader medium change needs the subscription); the remount-on-replug
 > end-to-end (the logic is in place; QEMU can't re-present the boot-controller