Harden ARCH_SET_FS against invalid FS base

[sangho2]

This PR hardens ARCH_SET_FS against invalid FS base values including kernel addresses and non-canonical values. Non-canonical values are particularly dangerous because they can result in a GP fault. This PR checks the value before writing it to the register.

[wdcui]

LGTM. GPT-5.5 found the following two potential issues:

1. High — invalid  clone(CLONE_SETTLS)  can still panic
    litebox_shim_linux/src/syscalls/process.rs:1635  calls  sys_arch_prctl(...).unwrap()  for clone TLS setup. With this PR, invalid user-controlled TLS
   now returns  RegisterUnpermittedValue , so clone can panic after thread creation instead of returning  EPERM . Validate  tls  in  do_clone  before
   spawning, or propagate the error instead of unwrapping.
2. Medium — FS base limit rejects valid Linux values
    litebox_common_linux/src/lib.rs:3218  uses  USER_ADDR_END , which excludes the final low-canonical guard page for RIP/RSP. Linux  ARCH_SET_FS 
   rejects  addr >= TASK_SIZE_MAX ; FS base does not need to be an executable/stack address. This over-rejects values in the final canonical user page.
   Use a dedicated FS-base/task-size limit instead of  USER_ADDR_END .

[wdcui]

@jaybosamiya-ms you should probably take a look at this PR as well since you worked on this part of the code.

[sangho2]

LGTM. GPT-5.5 found the following two potential issues:

1. High — invalid  clone(CLONE_SETTLS)  can still panic
    litebox_shim_linux/src/syscalls/process.rs:1635  calls  sys_arch_prctl(...).unwrap()  for clone TLS setup. With this PR, invalid user-controlled TLS
   now returns  RegisterUnpermittedValue , so clone can panic after thread creation instead of returning  EPERM . Validate  tls  in  do_clone  before
   spawning, or propagate the error instead of unwrapping.
2. Medium — FS base limit rejects valid Linux values
    litebox_common_linux/src/lib.rs:3218  uses  USER_ADDR_END , which excludes the final low-canonical guard page for RIP/RSP. Linux  ARCH_SET_FS 
   rejects  addr >= TASK_SIZE_MAX ; FS base does not need to be an executable/stack address. This over-rejects values in the final canonical user page.
   Use a dedicated FS-base/task-size limit instead of  USER_ADDR_END .

1. Make sense. I'm going to fix it.
2. Linux kernel rejects FS base in the final canonical user page and this PR mirrors this.

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.