Optimize Bunnymark and DOOM application hot paths

[frostney]

Summary

• alias immutable generated raylib imports once in Bunnymark and keep bunny simulation state in scalar numeric fields
• prepack DOOM palette bytes and expand indexed frames through paired byte/32-bit views with the pixel count cached outside the hot loop
• add GPL-side palette equivalence coverage and record the reproduced application-level performance evidence

Why

Profiling showed two proven project-side costs. Bunnymark repeatedly resolved imported raylib bindings inside its sprite loop and used FFI-backed vector fields for simulation state. DOOM reread a typed-array length and expanded three palette bytes plus alpha for every pixel of every frame.

These changes remove that repeated application work without changing GocciaScript runtime semantics, adding speculative shaders or batching, or crossing the repository's MIT/GPL package boundary.

Impact

On an Apple M1 Max with GocciaScript 0.10.0 in bytecode mode:

• Bunnymark's five 10,000-sprite, 25-frame trials averaged 12.13 FPS for the measured frame portion, versus the retained 4.00 FPS profiling baseline.
• DOOM's three 30-frame runs averaged 9.062 seconds, versus 13.30-13.41 seconds for the retained baseline, reducing end-to-end execution time by about 32%.
• The DOOM frame-8 screenshot had zero changed pixels below the FPS overlay compared with the byte-wise conversion baseline.

The palette implementation writes RGBA bytes first and then uses matching Uint32Array views for lookup and framebuffer copy, preserving byte order portably rather than relying on host-specific packed integer constants.

Validation

• npm test — 8/8 tests in interpreter and bytecode modes
• make -C examples/doom-gpl test-palette — 1/1 test and 1,024 byte assertions in each mode
• npm run check:generated
• npm run test:types
• npm run pack:check
• real Bunnymark startup smoke
• real 12-frame Freedoom gameplay and screenshot smoke
• GPL upstream source pin verification
• git diff --check