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-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