reorg: docs — library/device/ + library/protocol/ structure

Update the docs to match the reorganized tree:

- driver-model.md: the "Families" graph now shows library/device/<domain>/
  (data + logic split) and library/protocol/ instead of the old bus/ + proto/
  sketch; add the microkernel note (the kernel's one library/ import is the
  device-abi data module) and the rule that a driver's hardware command set is
  not a service-seam protocol.
- README.md "Repository layout": device-abi and the protocols move out of
  system/ into library/device/ and library/protocol/; rewrite the "public
  interface as a module" paragraph around the protocol tree and the device
  domains; fix the source-map paths.
- Sweep every remaining stale path reference across docs/ to the moved files.
- Fix vfs-protocol.zig's own header (the standalone VFS server retired; the fat
  server is the backend today).

zig build + test green.

docs/display.md

@@ -33,7 +33,7 @@ which one you're holding decides what you can do.
   you *is* that device's linear-framebuffer BAR — the same physical memory, seen through
   a different door. On a real discrete GPU, GOP's `base` is an aperture inside the GPU's
   VRAM BAR. danos already decodes this device
-  ([pci-class.zig](../system/devices/pci-class.zig) has the full `display` namespace, and
+  ([pci-class.zig](../library/device/pci/pci-class.zig) has the full `display` namespace, and
   `pci-bus` already reports it to the [device manager](device-manager.md) with its class
   triple) — but nothing binds it yet.
 
@@ -72,7 +72,7 @@ rest of the system hasn't had to face:
 2. **danos had no cross-process shared memory.** At v1 the memory syscalls were `mmap`
    (private, zeroed), `mmio_map` (a *claimed device's* MMIO), and `dma_alloc` (new
    pinned physical). The block driver's "pass a buffer by physical address" trick
-   ([block/protocol.zig](../system/services/block/protocol.zig)) works *only because its
+   ([block/protocol.zig](../library/protocol/block/block-protocol.zig)) works *only because its
    consumer is DMA hardware*. A compositor that CPU-reads and blends client layers can't
    use it — it would have to *map* another process's memory, which nothing allowed. v1
    sidesteps it entirely (see "What v1 does not do"); v2 has since built the primitive