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

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

@@ -104,12 +104,19 @@ and /system/logs), closing the two-sticks question honestly.
 **Filesystems (per volume, one process).** The proven unit everywhere from
 Plan 9's `dossrv` to Minix to Fuchsia: block-client + engine + file-protocol
 provider in one binary, one process per volume (9front practice; per-volume
-fault isolation is what our supervision makes cheap). fat's shell becomes a
-shared *filesystem harness* library before a second engine is written; a
-partition walk is added in the volume manager (`partition.zig`) — the engine's
-own MBR walk currently remains alongside it; write caching stays
-inside the process (the anti-fsyncgate rule). Each mounts its prefixes into the
-kernel mount table itself, exactly as today.
+fault isolation is what our supervision makes cheap). fat's shell became a
+shared *filesystem harness* library (`library/kernel/file-system-harness`), and
+the second engine — **exFAT**, `system/services/exfat` — now reuses it wholesale:
+the reuse this design promised, proven. exfat is nothing but the exFAT engine +
+a near-clone of fat's thin service, full read + write + directories + rename +
+on-disk up-case folding, differing only in the format it wraps. A partition walk
+lives in the volume manager (`partition.zig`), which recognizes fat vs exFAT by
+VBR and routes each to its engine; write caching stays inside the process (the
+anti-fsyncgate rule). Each mounts its prefixes into the kernel mount table
+itself. Two surface limits are shared across both engines and are the vfs
+layer's, not an exFAT shortcut: file offsets are u32 (a 4 GiB addressable cap),
+and file names are ASCII bytes (a non-ASCII unit becomes `?`) — teaching the vfs
+name layer UTF-8 is a separate cross-cutting change.
 
 **Kernel: two small changes only.** `fs_unmount` gains ownership (only the
 mounting endpoint's holder may unmount — possession-is-capability, consistent