.vmfb parity acceptance run (eager vs compiled)

[michalharakal]

关注-up of #1134. SKEEP-003 names "a .vmfb parity run" as the acceptance test for compiled parity (P7 in the SKEEP's phase numbering), scheduled after M2. M2 is done; no issue tracked this until now.

Scope

• An in-repo (or CI-adjacent) harness that takes a small model through HloGenerator → MLIR + .irpa → iree-compile → iree-run-module and compares numerics against the eager path. The external skainet-iree-conformance harness is the starting point; the gap is making it a repeatable acceptance gate rather than a manual run.
• This is the "in-repo IREE consumer" that unblocks the metadata-carry work (see sibling issue).

Acceptance

• One model (e.g. the sinus approximator or grayscale CNN) passes eager-vs-compiled numeric parity in a scripted run, documented well enough to rerun at release time.

[michalharakal]

Scope reframing (michalharakal): IREE validation will be approached with more focus than an in-repo harness —

1. IREE tooling lives in its own repository (SKaiNET-IREE-tools);
2. IREE conformity has its own repo, depending on SKaiNET-transformers;
3. simple FNNs are interesting to validate, but real-life transformers are what matters — so the path is: release SKaiNET core → adopt it in SKaiNET-transformers → run conformity there.

IREE validation will probably be specified as its own SKEEP later. This issue stays open as the placeholder until that SKEEP exists; an ad-hoc in-repo simple-FNN harness should not be built in the meantime. Carriage (#1147, slices #1178–#1180) proceeds first per the earlier re-order — its consumer is the conformity pipeline once the release lands.