AOT GGUF converter for I2_S repack (eager-exec) — done; IREE leg moved out of core

[michalharakal]

Sub-issue of #1198.

Why this, not just #1204's sidecar

The on-device sidecar cache (#1204) pays its "convert once" cost by doubling the first cold
start — decode + re-encode + write-to-disk, on the exact device class (constrained, e.g. a 2GB
phone) this whole effort is trying to protect. That's in tension with how this codebase already
treats cost elsewhere: PlannerProfile's own philosophy is that a cost should be visible and
paid deliberately, not quietly incurred as a surprise multiple of a weight's size (see
PlannerProfile.MOBILE_2GB's strict mode, skainet-lang-core/.../memory/plan/PlannerProfile.kt).
A silent 2x-cost first load is exactly that kind of surprise, and sits oddly next to a DSL/runtime
that otherwise insists costs be visible and chosen, not incurred quietly.

Two things already established in this thread point to a better fix:

• NeoGPU (the vendored ternary kernel's own upstream author) never does a runtime repack at all —
  its own converter (convert_bitnet_to_gguf.py) emits the kernel-ready SEQUENTIAL layout
  offline, ahead of time.
• The IREE-compiled leg already has a real AOT checkpoint (iree-compile) where this repack folds
  in for free — ExternalParameterRef's .irpa packager
  (skainet-compile-hlo/.../hlo/ConstantMaterialization.kt:84-90) already wants verbatim,
  kernel-ready bytes for its zero-copy path, and hits the exact same I2_S blocker the eager-exec
  loader does.

Proposed change

A shared conversion module: read any supported source format, apply whatever repack/relayout each
target dispatch key needs (I2sRepack.toSequentialPayload for ternary, Q4_K/Q5_K feed-order via
TensorView.prepack(), etc. — the same logic #1202's kernels already dispatch against), then emit
either:

• a kernel-ready GGUF/sidecar for the eager-exec loader to consume AS_STORED — zero runtime
  transformation, real mmap via AllocationResolver's existing fileBytesAreTheBytes gate.
  skainet-io/skainet-io-gguf/.../export/GGUFWriter.kt already knows GGUF's binary format today
  (for exporting a SKaiNET-authored ComputeGraph, not yet for round-tripping an existing GGUF) —
  real infrastructure to extend, not a green field.
• an .irpa parameter archive for the IREE leg, via skainet-io-iree-params's IrpaWriter.

Both outputs share the same repack step; only the container differs. This is the primary
mechanism whenever a build controls its own model pipeline (ships specific converted models, not
arbitrary user-supplied GGUFs) — the common production case, and the one this DSL's other export
paths (Minerva, StableHLO/IREE) already assume.

Relationship to #1204

#1204's on-device sidecar is demoted to an explicit fallback, not the default recommendation:
still needed for the case where a consumer loads a GGUF this AOT tool never saw (a user picks an
arbitrary HuggingFace file at runtime), but not the first thing to build and not what a build with
a fixed model set should reach for.

Verification

• Round-trip test: AOT-convert a synthetic I2_S GGUF (both GROUP_128/GROUP_64 inputs), load the
  converted output through the eager-exec loader, assert decoded values match the non-converted
  reference bit-for-bit.
• Confirm the converted output resolves to MemoryDomain.MMAP_FILE via
  AllocationResolver.explain() — no repack, no off-heap allocation, nothing to cache at load time
  at all.
• .irpa side: confirm IrpaWriter accepts the converted, kernel-ready bytes as an
  ExternalParameterRef without re-encoding.

[michalharakal]

Splitting scope after further discussion, and closing the loop on where the IREE-facing half
belongs.

Eager-exec half: done. #1210 implements I2sAotConverter — reads an arbitrary GGUF, repacks
I2_S to SEQUENTIAL+trailer, passes everything else through byte-for-byte, writes a converted
GGUF that takes #1203's zero-copy mmap path with no runtime repack at all. This has no compiler
dependency — it's pure GGUF I/O, squarely core's job, same as the existing GGUF reader/writer.

IREE/.irpa half: descoped from this repo entirely, not just deferred. This repo's own
SKEEP doc already draws the line clearly (docs/modules/skeep/pages/004-virtual-tensor-layout.adoc:153-155):
core hands off neutral .mlir + .irpa artifacts; iree-compile itself, and everything
specific to consuming those artifacts for a given compiled target, lives in SKaiNET-IREE-tools.
Building IREE-specific conversion/packaging logic inside SKaiNET core would just relocate the
same coupling this repo is otherwise careful to avoid — and the same question will come up again
verbatim the day XLA (or any other compiled target) needs support. The right boundary is: each
compiled-target integration owns its own conversion/packaging tooling in its own repo,
consuming core's neutral export contract, rather than core growing a conversion path per target.

So: the IREE-facing conversion work tracked here moves to SKaiNET-IREE-tools (or a new public
sibling repo, once available) rather than continuing under this issue. This issue is closed out
as "eager-exec done, IREE-facing half relocated" — not left open as unfinished core work.

[michalharakal]

IREE-facing half now underway in the right place: SKaiNET-developers/SKaiNET-IREE-tools#1 (convert/gguf_to_irpa.py — GGUF I2_S → .irpa, deliberately reimplementing I2sRepack.kt/I2sScale.kt/IrpaWriter.kt standalone so that repo's tools don't need the SKaiNET JVM toolchain; rationale and the authoritative-source note are in that repo's convert/README.md).

[michalharakal]

Closing as complete per the close-out comment above: the eager-exec half (I2sAotConverter + round-trip test) shipped in 0.51.0 (PR #1210), and the IREE leg was deliberately descoped to SKaiNET-IREE-tools#1. The close itself was the only missing step.

One note for consumers: the converter is a library API only — no CLI entry point exists in skainet-apps/. If a runnable converter tool is wanted, that's a new (small) issue.

Cross-repo status: the BitNet application layer this feeds is tracked in SKaiNET-developers/SKaiNET-transformers#335 (residuals: transformers#357, transformers#358, transformers#360) and the SPI gap SKaiNET#1240.