Fix ARM64 fork kernel stack reuse for bsshd

[ryanbreen]

Summary

• replace the ARM64 kernel stack bump allocator with bitmap-backed reuse
• move fork-child kernel stack ownership into the scheduler clone so waitpid cannot free a stack while CPU scheduler state may still reference it
• reclaim fully retired terminated scheduler threads before ARM64 fork consumes another stack slot

Root cause

TURN 337 reproduced the inbound bsshd degradation on a fresh ARM64/Parallels boot at strict-host-key handshake 91, after 90 successful SSH exec sessions. Serial showed bsshd accepted the connection and reached fork, then failed with Os(ENOMEM). That points to ARM64 fork/kernel-stack allocation, not TCP receive or userspace SSH packet handling.

Verification

• rustfmt --check kernel/src/memory/kernel_stack.rs kernel/src/process/manager.rs kernel/src/task/scheduler.rs kernel/src/arch_impl/aarch64/syscall_entry.rs
• git diff --check -- kernel/src/memory/kernel_stack.rs kernel/src/process/manager.rs kernel/src/task/scheduler.rs kernel/src/arch_impl/aarch64/syscall_entry.rs
• cargo build --release --features testing,external_test_bins --bin qemu-uefi (exit 0, warning/error grep empty)
• fresh ARM64 Parallels run: 150/150 strict-host-key inbound bsshd handshakes with echo OK-FIXED2-NNN && uname

Artifacts: /Users/wrb/Downloads/Ralph/breenix-interrupt-io-roadmap-1780056222/turn337-artifacts/

Note: full cargo fmt is still blocked by pre-existing unrelated trailing whitespace in tests/shared_qemu.rs; the touched files were checked with rustfmt directly.