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/threading.md

@@ -133,7 +133,7 @@ Deviations from `std.Thread`, called out honestly:
 ## Kernel primitives (new private syscalls)
 
 Four new entries extend [abi.zig](../system/abi.zig) `SystemCall` after
-`shm_physical = 36`, each with a `library/runtime` wrapper:
+`shared_memory_physical = 36`, each with a `library/runtime` wrapper:
 
 | Syscall | Signature | Purpose |
 |---|---|---|
@@ -210,7 +210,7 @@ Keying: threads share an address space, so a **virtual address within that addre
 identifies a futex uniquely; the kernel keys its wait queue by `(address_space_root, virtual_address)`.
 Keying by the **physical** address instead (translate `virtual_address -> physical_address` on entry) is a
 deliberate forward door: it lets two *processes* share a futex through an
-[shm](display-v2.md) region later, without changing the API. We start with the
+[shared-memory](display-v2.md) region later, without changing the API. We start with the
 private-per-address-space key and note the physical-key upgrade.
 
 No spinning: a contended lock parks the task in the kernel and the core is free to run