Stabilize the runtime/KOS thread boundary

[drpaneas]

Summary

The runtime is effectively single-native-threaded, but that contract is implicit and the scheduler currently rewrites KOS thread stack metadata while goroutines run.

Why

• The runtime uses global current_g / current_tls, so accidental entry from another native thread can corrupt runtime state.
• Rewriting thd_current->stack is a fragile contract with interrupts, KOS services, debugging, and unwinding.
• The native-thread model should be explicit and enforceable rather than accidental.

Evidence

• runtime/tls_sh4.c: current_g and current_tls are global state.
• runtime/scheduler.c: run_goroutine() saves thd_current->stack, replaces it with gp->stack_lo, then restores it later.
• runtime/runtime_stubs.c: runtime_NumCPU() and runtime_GOMAXPROCS() always return 1.

Direction

• Make "all Go runs on one attached KOS thread" an explicit runtime contract and panic on foreign-thread entry.
• Keep KOS thread metadata stable while switching Go contexts.
• If needed, isolate the fiber bridge in one low-level module instead of spreading KOS-thread assumptions across the scheduler.