coro: compact frames and native allocation classes

[cpunion]

Summary

• reuse coroutine scratch storage and streamline exact tail/completion paths
• embed scheduler metadata in compiler-owned frames and remove duplicate/dead frame fields
• size borrowed storage exactly for native and wasm32 targets
• use tighter O(1) native allocation classes with tiered cache budgets

Space and allocation results

• scheduler Frame: 160 -> 96 bytes on pointer-64; reserved borrowed storage: 80 -> 52 bytes on pointer-32
• compiler/runtime header: 56 -> 48 bytes on pointer-64 and 36 -> 28 bytes on pointer-32
• common emitted LLVM coroutine frame: 344 -> 224 bytes
• common dynamic request: 255 bytes including receipt/alignment, fitting the 256-byte class
• representative 551-byte request: 576-byte class instead of 1024 bytes
• 53 arithmetic native classes; lazy bounded retention stays below 3.6 MiB across all bins

The private scheduler metadata stays byte-addressable rather than packing hot lifecycle/completion state into bitfields. A further one-word native reduction would add masks and conversions to high-frequency scheduler transitions for only about 3.6% of the common 224-byte frame, so this series keeps the faster 96-byte layout.

Validation

• runtime coro, allocator, and scheduler unit tests
• compiler coroutine ABI/outcome/defer/panic/frame tests
• bootstrap factory test
• wasm32 compile-time layout assertions and LLGo WASI fixture
• native spawn, park, handoff, timer, select, panic, and recover workloads
• paired spawn benchmarks showed no stable throughput regression