exfat: the in-VM mount + mutation drill (S4 step 8)

exfat-volume attaches a bare exFAT data device (serial e0fa0001, from
make-exfat-image.py) beside the FAT boot volume. The volume manager
content-routes it to the exFAT service — not fat — which mounts it at
its id-path /volumes/exfat-e0fa0001; the exfat-test client then reads the
seeded HELLO.TXT and mutates through the mount (mkdir/write/rename/read/
remove). The second engine reusing the shared harness is now proven end
to end, on a real device, in QEMU.

The drill caught what host tests could not: the exfat service was denied
openEndpoint("volume-manager") — it had no protocol.csv grant — so its
hello never reached the manager and its volume never mounted (a silent
spin, no fault). Added the grant mirroring fat's. A new exfatVolumeTest
kernel case boots the tree and spawns the fixture; the run harness grows
an exfat data-volume flavor. Fails against pre-S4 (no exfat binary, csv
row, VBR recognizer, or grant).

system/configuration/protocol.csv

@@ -102,6 +102,8 @@
 # own endpoint (the mouse-listener thread opens /protocol/display like any other
 # client — threads share no handles), and the input stream that moves the cursor.
 /system/services/fat,                        /system/services/volume-manager, open,       volume-manager
+# exfat reaches the volume manager the same way — the second engine, same lineage.
+/system/services/exfat,                      /system/services/volume-manager, open,       volume-manager
 # The volume manager reaches the device manager to be routed to each storage
 # provider's block channel, then confines a filesystem to each volume.
 /system/services/volume-manager,             /system/services/init,           open,       device-manager