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.

system/kernel/tests.zig

@@ -1744,9 +1744,9 @@ fn threadAllocTest(boot_information: *const BootInformation) void {
     result();
 }
 
-/// Per-thread TLS / fs.base (docs/threading-plan.md M10): `thread-test` in tls mode has two
+/// Per-thread TLS / FS base (docs/threading-plan.md M10): `thread-test` in tls mode has two
 /// threads each set their own FS base and write a unique marker to `%fs:8`, then — after
-/// both have written — read it back. If fs.base were not per-thread and restored across
+/// both have written — read it back. If the FS base were not per-thread and restored across
 /// context switches, the second write would clobber the first and a thread would read the
 /// wrong marker. The verdict marker means both read their own value (no cross-talk).
 fn threadTlsTest(boot_information: *const BootInformation) void {
@@ -1783,7 +1783,7 @@ fn threadTlsTest(boot_information: *const BootInformation) void {
     }
     scheduler.setPriority(4);
 
-    check("each thread has its own fs.base TLS slot (no cross-talk across switches)", bufferHas(ok_marker) and !bufferHas(fail_marker));
+    check("each thread has its own FS-base TLS slot (no cross-talk across switches)", bufferHas(ok_marker) and !bufferHas(fail_marker));
     result();
 }
 

system/services/thread-test/thread-test.zig

@@ -357,7 +357,7 @@ fn runAllocMode() void {
     write("thread-alloc: ok\n"); // the M7 verdict marker
 }
 
-// --- M10: tls mode (per-thread fs.base storage) -----------------------------
+// --- M10: tls mode (per-thread FS base storage) -----------------------------
 
 fn writeTlsSlot(value: u64) void {
     asm volatile ("movq %[v], %%fs:8"
@@ -379,9 +379,9 @@ var tls_ok = std.atomic.Value(u32).init(0);
 fn tlsWorker(marker: u64) void {
     writeTlsSlot(marker);
     _ = tls_written.fetchAdd(1, .release);
-    // Wait until both threads have written their own slot. If fs.base were shared, the
+    // Wait until both threads have written their own slot. If the FS base were shared, the
     // second write would clobber the first, and the read below would return the wrong
-    // marker — cross-talk. Per-thread fs.base keeps each thread's slot private.
+    // marker — cross-talk. A per-thread FS base keeps each thread's slot private.
     var spins: usize = 0;
     while (tls_written.load(.acquire) < 2 and spins < 50_000_000) : (spins += 1) {
         runtime.system.yield();
@@ -406,7 +406,7 @@ fn runTlsMode() void {
     if (tls_ok.load(.acquire) == 2) {
         write("thread-tls: ok\n"); // the M10 verdict marker
     } else {
-        write("thread-tls: FAIL cross-talk (fs.base not per-thread)\n");
+        write("thread-tls: FAIL cross-talk (FS base not per-thread)\n");
     }
 }