threads: name the TLS thread pointer arch-neutrally (not fs.base)

The M10 TLS work leaked x86 naming into the generic kernel: Task.fs_base,
PerCpu.loaded_fs_base, and architecture.setFsBase. The *mechanism* was already
abstracted (the generic scheduler calls through the architecture layer; the
wrmsr IA32_FS_BASE lives in architecture/x86_64/cpu.zig), but the *names* would
force an aarch64 port to implement a 'setFsBase' that writes TPIDR_EL0.

Rename to the neutral concept: Task.thread_pointer, PerCpu.loaded_thread_pointer,
architecture.setThreadPointer (x86_64 impl writes IA32_FS_BASE; aarch64 -> TPIDR_EL0).
Also neutralise the user_arg comment (first argument register, rdi on x86_64).
No behaviour change; thread-tls/thread-mutex/smp/process-kill + host tests pass.

system/kernel/architecture/x86_64/cpu.zig

@@ -306,10 +306,12 @@ pub fn cpuLocal() usize {
 
 const ia32_fs_base = 0xC000_0100;
 
-/// Set the FS-segment base — the x86_64 thread pointer for user-space TLS. The kernel
-/// never touches FS, so this only affects the user task that runs next; the scheduler
-/// restores it per task across context switches (docs/threading-plan.md M10).
-pub fn setFsBase(base: u64) void {
+/// Set the user-space TLS **thread pointer** — the arch-neutral name the generic scheduler
+/// calls (`architecture.setThreadPointer`). On x86_64 that is the FS-segment base
+/// (`IA32_FS_BASE`); an aarch64 port implements the same call against `TPIDR_EL0`. The
+/// kernel never touches FS, so this only affects the user task that runs next, which the
+/// scheduler restores per task across context switches (docs/threading-plan.md M10).
+pub fn setThreadPointer(base: u64) void {
     io.wrmsr(ia32_fs_base, base);
 }