naming: shm → shared_memory — 'shm' is a Unix clipping, not an acronym

Per docs/coding-standards.md (no Unix-abbreviation exception): syscalls
shared_memory_create/map/physical, kernel SharedMemoryObject + handlers,
runtime.shared_memory (library/runtime/shared-memory.zig), the
shared-memory-server/-client test services, the shared-memory QEMU case,
and docs incl. vdso.md's danos_shared_memory_*. 87/87 QEMU tests pass.

docs/display-plan.md

@@ -134,7 +134,7 @@ Prove the pipeline end-to-end from a separate process.
       every IPC message at `MESSAGE_MAXIMUM` = 256 — so `replyWait` rejected the oversized
       receive buffer with `-E2BIG` and the serve loop had been *spinning* since D2 (unseen,
       as D2/D3 matched init-time heartbeats). Set it to 256; `blit_tile` is now explicitly
-      a small-tile path (≤ 54 px inline), larger bitmaps being the deferred shm surface.
+      a small-tile path (≤ 54 px inline), larger bitmaps being the deferred shared-memory surface.
 
 **Gate (met):** `python3 test/qemu_test.py display-demo` spawns the service + `display-demo`;
 the demo drives a run of frames of motion through the layer client API and logs
@@ -172,7 +172,7 @@ documented (docs/display.md): no runtime mode-setting (native backend) and no tr
 ## Deferred (explicitly not in this plan)
 
 - **Shared-memory surfaces** — generalize M13 capability passing to memory objects
-  (`shm_create`/`shm_map`), so bitmap clients hand the compositor a rendered surface
+  (`shared_memory_create`/`shared_memory_map`), so bitmap clients hand the compositor a rendered surface
   instead of drawing commands. The compositor's layer model already anticipates it.
 - **Native backend (Bochs DISPI, then virtio-gpu)** — behind the same internal backend
   interface as the dumb framebuffer: EDID mode list + runtime resolution/bpp change +