docs+code: drop misleading fs.base notation for the thread pointer

The "fs.base" spelling read like a field/submodule access, but no such
identifier exists — it meant the x86_64 FS segment base (the IA32_FS_BASE
MSR). Two problems fixed:

- Arch-neutrality: in generic docs, the runtime, and the plan, the mechanism
  is now named by its arch-neutral concept — the "thread pointer" — matching
  the already-renamed `thread_pointer` Task field, `set_thread_pointer`
  syscall, and `architecture.setThreadPointer` fn. x86-specific spots keep
  the precise names: `IA32_FS_BASE` (the MSR), `%fs:8`/`%fs:0`, variant-II.

- Stale identifiers: the M10 section in threading-plan.md still referenced
  `fs_base` on Task and `architecture.setFsBase` — both renamed away in the
  arch-neutral pass. Corrected to `thread_pointer` / `setThreadPointer`.

The x86-only `thread-tls` test (which really does write `%fs:8`) now says
"FS base" (no dot) consistently, matching the established form already in
tests.zig. The matched serial markers ("thread-tls: ok" / "thread-tls:
FAIL") are unchanged; only a non-load-bearing FAIL parenthetical was
reworded.

Verified: zig build clean, thread-tls passes.

docs/threading.md

@@ -5,9 +5,9 @@ A note on danos **threads** — several tasks sharing one address space — prov
 kernel entry behind the [runtime](../library/runtime). **Built** (M1–M11, see
 [threading-plan.md](threading-plan.md)): `spawn`/`join`/`detach`, cross-core parallelism,
 a futex, `Mutex`/`Condition`/`Semaphore`/`RwLock`/`WaitGroup`, `getCurrentId`/`currentCore`,
-per-thread `fs.base` TLS, thread-safe allocation, and a task reaper that reclaims dead
+per-thread thread-pointer TLS, thread-safe allocation, and a task reaper that reclaims dead
 tasks' kernel stacks. Deferred by design (no consumer yet): the Zig `threadlocal`
-*compiler* layer (per-thread `fs.base` is in place, so it's runtime+linker work on top) and
+*compiler* layer (the per-thread thread pointer is in place, so it's runtime+linker work on top) and
 detached-thread user-stack reclaim — see the plan's M9/M10 notes. The analysis is against
 **Zig 0.16** (the pinned toolchain); `std.Thread`'s internals move between releases, so
 treat upstream shapes as "0.16.x."
@@ -219,12 +219,12 @@ decision, not a "maybe later."
 
 ### TLS and `getCurrentId`
 
-danos sets up no `fs.base` TLS today (fine under `single_threaded`). Two scoped needs:
+danos sets up no thread-pointer TLS today (fine under `single_threaded`). Two scoped needs:
 
 - **`getCurrentId`** returns the kernel task id — either a trivial syscall or, better,
   a value the runtime stashes in a per-thread control block.
-- **`threadlocal` variables** need a real per-thread TLS block and `fs.base` set per
-  thread. `thread_spawn` sets `fs.base` to a runtime-allocated per-thread block; full
+- **`threadlocal` variables** need a real per-thread TLS block and the thread pointer set per
+  thread. `thread_spawn` sets the thread pointer to a runtime-allocated per-thread block; full
   `threadlocal` support is Stage 3, only if a consumer needs it. Nothing in the core
   spawn/join/mutex path requires `threadlocal`.
 
@@ -273,7 +273,7 @@ a verifiable gate (`python3 test/qemu_test.py <case>`, asserting serial markers;
   word. *Gate:* `-Dtest-case=thread-mutex` — a bounded producer/consumer over a
   `Mutex` + `Condition` moves K items with no lost wakeups and no busy-wait (assert
   the consumer blocked, e.g. via a low idle tick count).
-- **Stage 3 — polish.** Per-thread TLS / `fs.base` and `threadlocal` (only if a
+- **Stage 3 — polish.** Per-thread TLS / thread pointer and `threadlocal` (only if a
   consumer needs it), `RwLock`/`WaitGroup` as demanded, and this doc's cases wired
   into [test/qemu_test.py](../test/qemu_test.py).