Add guard pages to every kernel thread stack

[mdpatelcsecon]

Summary

Each Thread owns a page-aligned StackBuf allocated via alloc_zeroed, but there is no guard page to catch overflows. Adding an unmapped guard page per stack would turn silent corruption into a clean fault and improve diagnostics.

Work Items

• Extend StackBuf so allocation and resize paths reserve an extra page and keep it unmapped, likely via the paging abstraction instead of raw alloc_zeroed.
• Decide which side of the stack hosts the guard (preferably below the stack bottom) and update any caller assumptions, particularly ThreadContext setup.
• Ensure drop/resizing logic tears down the guard mapping cleanly.
• Add a self-test in self_test::memory that intentionally overruns the stack and asserts we trap or panic as expected.
• Audit for architecture-specific assumptions so future aarch64/riscv64 support can reuse the abstraction.

Acceptance Criteria

• Kernel builds and boots with make build-x86_64-debug.
• New self-test passes, demonstrating the guard page trips as expected.
• Logging or instrumentation shows guard pages are present and unmapped on thread creation.
• Relevant docs mention guard pages for thread stacks.