C6: update docs for the library/kernel + client split

Rewrote the repository-layout and driver-model docs to describe the new tree —
library/kernel (the kernel32-style system library: syscall surface split by
concern), library/device (mmio/model/pci/usb/acpi/driver/block), library/client
(display, input service clients), library/protocol (wire contracts) — and swept
the reference docs off the retired runtime shim:

  runtime.system.*  -> logging.* / time.* / process.* / memory.*
  runtime.dma.* / runtime.shared_memory.* / runtime.allocator -> memory.*
  runtime.ipc/process/time/service/Thread/block/display/input -> the module name
  runtime.device / runtime.device_manager -> driver
  library/runtime/<file>.zig -> its new home (kernel/ client/ device/)

docs/README.md (repository layout + source map), docs/driver-model.md (the module
graph + import lists), and the concern/reference docs (ipc, threading, timers,
logging, power, process-lifecycle, device-manager, display, vdso, sysv, drivers,
input, vfs-protocol, coding-standards, ...) now reflect the split. "runtime" that
remains is the userspace-library *concept*, which is still accurate.

The historical plan docs (display-plan, display-v2-plan, threading-plan) and the
zig-self-hosting design note are left as point-in-time snapshots.

docs/display.md

@@ -96,7 +96,7 @@ rest of the system hasn't had to face:
      ▼   reached by name (ipc_lookup); clients drive it over the display protocol
   ┌────────────────────────────────────┬──────────────────────────────────────┐
   drawing clients (v1)                  surface clients (deferred)
-  runtime.display commands:             runtime.display surfaces:
+  display commands:             display surfaces:
     create_layer / configure_layer        shared_memory_create → pass as a capability →
     fill_rect / blit_tile / damage         the compositor maps & composites the
     present                                client-rendered bitmap directly
@@ -106,7 +106,7 @@ The bring-up sequence mirrors a hardware driver's — it is the
 [`usb-xhci-bus` `initialise`](../system/drivers/usb-xhci-bus/usb-xhci-bus.zig) shape
 (claim → `mmio_map` → run loop) — and the request/reply service shell is the
 [FAT](../system/services/fat/fat.zig) / [input](../system/services/input/input.zig) shape
-([`runtime.service.run`](../library/runtime/service.zig) with a `protocol.zig` of
+([`service.run`](../library/kernel/service.zig) with a `protocol.zig` of
 `extern struct` messages and an `Operation` tag).
 
 **One process, for now.** v1 is a *single* service that both owns the framebuffer and
@@ -222,13 +222,13 @@ pacing on backends that have none (all of them today; see
 [display-v2.md](display-v2.md), "Fenced is not vsync"). Bring-up paths that must put
 pixels on screen synchronously (initialisation, the self-checks) bypass the clock.
 
-## `runtime.display`
+## `display`
 
-Clients speak the protocol through a new [`library/runtime/display.zig`](../library/runtime/runtime.zig),
-the [`runtime.block`](../library/runtime/block.zig) shape (a cached `.display` lookup
+Clients speak the protocol through a new [`library/client/display/display.zig`](../library/client/display/display.zig),
+the [`block`](../library/device/block/block.zig) shape (a cached `.display` lookup
 with a boot-race retry): `display.info()`, a `Layer` handle with `fill` / `blitTile` /
 `damage`, and `present()`. Application code never issues the raw syscalls — it calls the
-runtime, as with every other danos service.
+client module, as with every other danos service.
 
 ## The cursor: a mouse-listener thread feeding the compositor
 
@@ -244,7 +244,7 @@ thread** beside the compositor loop.
   the compositor — so no lock guards the framebuffer. A parked `next()` leaves its core
   free to halt ([halting.md](halting.md)).
 - **The channel.** A single-slot *latest-value* cell (`CursorChannel`) guarded by a
-  `runtime.Thread.Mutex`: the renderer wants where the cursor *is now*, not a replay of
+  `Thread.Mutex`: the renderer wants where the cursor *is now*, not a replay of
   every delta, so a new position overwrites the old. The listener also **pokes** the
   compositor awake — the main loop is parked in `replyWait`, so the listener posts a
   zero-payload `ipc.send` to the compositor's endpoint, which arrives as a