feat(gemma4): add standalone Gemma 4 MoE runtime

[jcolozzi]

Summary

Add a standalone Gemma 4 MoE runtime that follows Colibri's dependency-free CPU design and disk-streamed expert model.

The smallest reviewable scope includes:

• GGUF loading, tokenizer/chat templates, sampling, tool declaration rendering, and image preprocessing/vision execution
• a tiered expert backend with bounded RAM residency, disk streaming, usage persistence, and asynchronous prefetch
• focused C tests plus llama.cpp oracle and numerical-validation utilities
• integration with Colibri's existing Makefile and CI, plus inspection tooling and implementation documentation

This PR intentionally does not add another build system, launcher/OpenAI gateway/WebUI integration, release packaging. CUDA kernel source validated during development is included, but wiring it into Colibri's existing platform-specific CUDA build conventions is left for follow-up.

AI disclosure

The implementation, tests, and documentation in this PR were fully generated with OpenAI Codex under my direction. I reviewed the resulting changes, resolved the upstream integration and scope, built and tested the code on Windows, exercised real Gemma 4 inference on CPU and CUDA during development, and take responsibility for the submitted code.

Validation

• Clean warning-enabled GCC/w64devkit build of gemma4.exe and all seven Gemma C test executables
• Seven focused Gemma C tests passed under GCC/w64devkit after the Make-only cleanup
• git diff --check
• make -C c check

The complete local check is currently blocked by pre-existing Windows/toolchain failures outside this diff:

1. The default DeepSeek V4 unit build forces -flto, but this w64devkit GCC reports that LTO support is unavailable. With the supported LTO=0 override, the untouched DeepSeek V4 test still fails to link coli_v4_layer_gpu*, coli_v4_engine_config, and coli_v4_route_bf16.
2. Running the Python gate independently executes 773 tests (49 skipped) and ends with two untouched FP8 harness failures: a subprocess command does not quote the C:\Program Files\... compiler path, and the E2E harness omits the Windows-required -D_FILE_OFFSET_BITS=64 definition.

Additional development validation, before narrowing the checked-in build integration to Make, included a warning-free Visual Studio 2022/CUDA 12.4 build, 7/7 focused tests, and real gemma-4-26B-A4B Q4 generation on a Quadro P1000 4 GB that produced Hello.

Compatibility

• The default Gemma CPU build has no new mandatory third-party dependency
• The checked-in build integration uses Colibri's existing Makefile
• No model files, generated binaries, packed weights, or benchmark artifacts are included
• PR targets dev and remains a single focused commit based on current upstream/dev

Follow-up

Separate changes can wire the validated CUDA kernel into Colibri's existing CUDA conventions and integrate Gemma with the current launcher/OpenAI gateway/WebUI and release packaging after the engine API and model behavior are reviewed.

[rofl0r]

CMake, really? why not add some meson and bazel to the mix? so everyone can have their favorite build system! 🤣

[jcolozzi]

Removed the standalone CMake build and updated the documentation to use Colibri's existing Makefile. The branch remains a single focused commit; the warning-clean Make build and all seven Gemma tests pass after the cleanup.