Make memory domains explicit in kos APIs

[drpaneas]

Summary

kos/ currently exposes raw pointers and ownership flags across several APIs even though the runtime uses a moving GC and multiple distinct memory domains.

Why

• Callers must remember by convention which buffers move, which must be freed manually, which live in VRAM, and which are safe for DMA.
• This increases misuse risk at the exact boundary where hardware bugs are hardest to diagnose.
• Safer typed wrappers would make the runtime's memory model visible to users instead of implicit.

Evidence

• kos/sound.go: SpuMemloadDma() accepts an ordinary Go []byte.
• kos/video.go: VramS() exposes raw VRAM as unsafe.Pointer.
• kos/fs.go: RomdiskMount() accepts unsafe.Pointer plus an own flag.
• kos/input.go: MapleDevice.Status() returns unsafe.Pointer.
• kos/vmu.go: ReadVmu() has to copy from a KOS-allocated buffer and free() it manually.

Direction

• Model GoHeap, ExternalHeap, DMABuffer, VRAMHandle, and borrowed KOS buffers as separate concepts.
• Keep raw FFI in an internal layer and expose typed handles at the public kos layer.
• Restrict DMA and hardware APIs to non-moving or explicitly pinned buffers.