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-plan.md

@@ -252,11 +252,11 @@ green.
 
 - [x] `getCurrentId` via a small `thread_self = 42` syscall (`runtime.Thread.getCurrentId`
       returns the kernel task id). **Per-thread `threadlocal` TLS is deferred** — no
-      consumer needs it, and it would require context-switching `fs.base` per task (real
-      kernel + per-switch cost) for an unused feature; threaded binaries have run fine
+      consumer needs it, and it would require context-switching the thread pointer per task
+      (real kernel + per-switch cost) for an unused feature; threaded binaries have run fine
       without it through M2–M5. threading.md's TLS reasoning already scoped it as
       deferred-unless-needed. When a consumer appears, the shape is: `thread_spawn`
-      allocates a per-thread TLS block, sets `fs.base`, and the context switch saves/
+      allocates a per-thread TLS block, sets the thread pointer, and the context switch saves/
       restores it.
 - [x] `RwLock` / `WaitGroup` deferred (no consumer yet); they slot onto the same
       `Futex`/`Mutex`/`Condition` when wanted.
@@ -280,7 +280,7 @@ cross-core parallelism, futex, and `Mutex`/`Condition`/`Semaphore`, all over a p
 thread ABI behind the runtime.
 
 **Phase 2 (M7–M11): built.** Thread-safe allocation (M7), a task reaper that reclaims dead
-tasks' kernel stacks (M8), endpoint-free `thread_join` (M9), per-thread `fs.base` (M10),
+tasks' kernel stacks (M8), endpoint-free `thread_join` (M9), the per-thread thread pointer (M10),
 and `RwLock`/`WaitGroup` + host-testable sync (M11). Two things stay deferred by design
 (no consumer): the Zig `threadlocal` *compiler* layer (M10) and detached-thread user-stack
 reclaim (M9) — both noted in place.
@@ -299,7 +299,7 @@ The organising principle, so Phase 2 reinforces danos's goals rather than erodin
   per-task **kernel** stack (kernel heap) — with a reaper (M8). This is the
   [resilience](resilience.md) restart guarantee, extended to threads.
 - **Kernel owns mechanism; the runtime owns policy.** The kernel maps pages, saves/
-  restores `fs.base`, and reaps dead tasks; the runtime decides allocation, TLS layout,
+  restores the thread pointer, and reaps dead tasks; the runtime decides allocation, TLS layout,
   and lock algorithms. Every new kernel entry stays a private syscall behind the runtime
   ([syscall.md](syscall.md)) — the ABI stays renumberable.
 - **The process is still the isolation and restart boundary.** Threads share fate within
@@ -400,25 +400,25 @@ guardrail 26/26 (incl. `process-kill`, `supervision`, `fault-recovery`, `task-re
 > translate/unmap in a not-currently-loaded address space — real complexity for a bounded leak.
 > A follow-up when a consumer needs it.
 
-### M10 — Per-thread TLS: the `fs.base` mechanism ✅
+### M10 — Per-thread TLS: the thread-pointer mechanism ✅
 
 Give each thread its own thread pointer and private TLS storage — the foundation
 self-hosting Zig ([zig-self-hosting.md](zig-self-hosting.md)) will build `threadlocal` on.
 
-- [x] **Kernel** stores `fs_base` on `Task` and restores it on every context switch
+- [x] **Kernel** stores `thread_pointer` on `Task` and restores it on every context switch
       **only when it changes** (the same conditional-load discipline as CR3;
-      `architecture.setFsBase` → `wrmsr IA32_FS_BASE`). A `set_thread_pointer(addr)` = 44
-      syscall sets the caller's `fs_base` and loads it now. The kernel never touches FS, so
-      there is no swapgs complication.
+      `architecture.setThreadPointer` → `wrmsr IA32_FS_BASE` on x86_64). A
+      `set_thread_pointer(addr)` = 44 syscall sets the caller's `thread_pointer` and loads it
+      now. The kernel never touches FS, so there is no swapgs complication.
 - [x] **Runtime** lays a small per-thread TLS block at the top of each thread's stack
       (self-pointer at `%fs:0` + scratch slots) and the thread trampoline calls
       `set_thread_pointer` before any user code — so every spawned thread has a private,
       switch-stable thread pointer. Reclaimed with the stack.
 - [x] `-Dtest-case=thread-tls` (`smp: 4`): two threads each write a unique marker to their
       own `%fs:8` slot and — after both have written — read it back; a shared (non-per-thread)
-      fs.base would clobber one and cause cross-talk. Both read their own marker → pass.
+      FS base would clobber one and cause cross-talk. Both read their own marker → pass.
 
-**Gate (met):** `thread-tls` passes (3×); full guardrail 25/25 (the switch-time `fs.base`
+**Gate (met):** `thread-tls` passes (3×); full guardrail 25/25 (the switch-time thread-pointer
 restore touches every context switch); `zig build`/`zig build test` clean.
 
 > **Deferred: the Zig `threadlocal` *compiler* layer.** Real `threadlocal` variables need
@@ -426,7 +426,7 @@ restore touches every context switch); `zig build`/`zig build test` clean.
 > in `user.ld`, a runtime that copies the template with exact negative-offset layout, and
 > the `.large`-code-model TLS section names — a high-uncertainty lift for a feature with
 > **no consumer today** (threading.md scopes it "only if a consumer needs it"). What lands
-> here is the load-bearing piece — per-thread `fs.base`, context-switched — so adding the
+> here is the load-bearing piece — the per-thread thread pointer, context-switched — so adding the
 > compiler layer later is purely runtime+linker work on top, no kernel change. `getCurrentId`
 > stays the `thread_self` syscall (M6) rather than an fs self-slot (which would need the
 > main thread's TLS set up in `_start` too).