Declared in-memory weight form, resolved from the target and the file (repack and dequant as stated intent)

[michalharakal]

Follows #1108, #973, and the M0 planner work (#1001).

The problem

How a weight ends up in memory is currently decided by three independent flags the caller sets on the loader:

existing	in	decides
StagingPolicy	skainet-io-core	heap bytes vs mapped pages
QuantPolicy	skainet-io-core	keep quantized / dequantize to FP32 / mixed
WeightOrientation	skainet-io-core	[in, out] as stored vs logical [out, in]

Three problems with that:

1. Nobody consults the target. Nothing asks the backend what its kernels can actually feed on. A Q4_K weight loaded on a target with no Q4_K kernel is a per-call dequantization nobody declared; the same weight on a target with a NEON kernel wants input-block-major bytes and gets canonical ones.
2. WeightOrientation stops at the shape. It reverses dimensions; it does not touch packed byte order. The order that matters to a kernel (Packed-quant byte-order (block layout) is an unwritten, contradictory contract across the engine and downstream converters #973) has no name in this vocabulary.
3. It is a caller decision that should be a resolved one. The information needed — what the file holds, what the device has, what the plan can afford — is available at load time, in one place. Making the user pick from three enums is asking them to do the resolution by hand, for a target they may not be building for.

Proposal

One declared desired in-memory form per model (overridable per tensor), resolved at load:

WeightForm(
    encoding: KeepAsStored | DequantizeTo(DType) | RequantizeTo(TensorEncoding),
    order:    AS_STORED | KERNEL_FEED,
    residency: HEAP | MAPPED,          // today's StagingPolicy
)

with a resolver whose inputs are what the file holds + PlannerProfile + the backend's kernel capabilities (already expressed in KernelKey's capability set). The default is "whatever the best available kernel for this encoding wants" — so the ordinary user declares nothing, and the answer differs correctly between a desktop and a 2 GB board.

Repacking and dequantizing become stated intent, executed once at load, rather than accidents discovered per forward pass. Concretely:

• a repack is the Packed-quant byte-order (block layout) is an unwritten, contradictory contract across the engine and downstream converters #973 relayout, done at the load boundary instead of on first use;
• a dequant is allowed and sometimes right — but it doubles or quadruples a tensor, so it must be visible before it happens.

Which is the point of tying it to the planner: MemoryPlan already models bytes per tensor, so a declared form changes the plan, and skainet-plan <gguf> shows the cost before the load. A form that does not fit the budget is a planner failure with a suggestion, not an OOM. Each conversion emits a TraceSink adapter event, so "why is this model 3 GB" has an answer in the trace.

Relationship to #1108

Complementary, not alternative. #1108 makes the DSL work whatever form the weight is in. This makes the form a decision someone made on purpose, with the cost visible. With both, the common path is: the loader put the weight in kernel feed order, so #1108's marker resolves to a matmul with no relayout at all.

Acceptance

• WeightForm + resolver in skainet-io-core, defaulted from PlannerProfile × backend kernel capabilities
• StagingPolicy / QuantPolicy / WeightOrientation expressed through it, deprecated with ReplaceWith, behaviour unchanged for callers who set them explicitly
• A repack or dequant chosen by the resolver appears in the MemoryPlan and in skainet-plan output, before the load
• Each conversion emits a trace event naming the tensor, the from-form and the to-form
• Golden parity: for every encoding, a model loaded under a resolved form produces bit-identical output to the same model loaded AS_STORED
• Same model, same code, two profiles (DESKTOP / MOBILE_2GB) resolve to different forms and both run

[michalharakal]

All six slices merged. Closing.

slice		PR
#1114	WeightForm + resolver + kernel capability query	#1119
#1115	the GGUF loader takes a WeightForm	#1121
#1116	a declared form changes the plan	#1122
#1117	every repack and dequant says so on the trace	#1123
#1118	two profiles, two forms, both run	#1125
#1120	packed storage that knows its own block order	#1127

Against the acceptance list

• WeightForm + resolver, defaulted from PlannerProfile × kernel capabilities — done, but in skainet-lang-core, not skainet-io-core as this issue said. io-core and backend-api are siblings over lang-core, and the resolver needs the profile from one side and capabilities from the other while the loader consumes its output; lang-core is the only module all three see.
• The three enums expressed through it and deprecated — done. StagingPolicy and WeightOrientation got a real ReplaceWith; QuantPolicy got a message only, because EncodingRequest is not a drop-in for it (RAW_BYTES has no counterpart, no loader having supported it) and a ReplaceWith that does not compile is worse than none.
• Repack and dequant visible in the plan before the load — done. MemoryPlans.plan prices residentBytes rather than the file's bytes, the weights line reads re-encoded at load (+N), and the conversion is named first in the suggestions because unlike --ctx or the KV mode nobody asked for it.
• A trace event per conversion — done, and for three conversions rather than one. The two the resolver does not cause are the ones most worth seeing: ternary widening to FP32 whatever the policy ([S2.7] P6: ternary encodings TQ1_0, TQ2_0, BITNET_B1_58 with block spec + activation hint; reference decoder and parity fixtures generated from the descriptor #1033, ~20×, no flag turns it off) and narrow-float doubling.
• Golden parity per encoding — done: all eight combinations of the old flags loaded twice, once through them and once through the equivalent form, compared element by element.
• Two profiles, two forms, both run — done, with the forms asserted to differ rather than assumed.

What the work turned up

#1124 — a pre-existing silent correctness bug: the common DefaultCpuOps computed packed matmul wrongly whenever the KernelRegistry was empty, by several times the magnitude of the answer. Found by #1118's end-to-end test, fixed in #1126. The blind spot was structural: the JVM tests always resolve to DefaultCpuOpsJvm, and the native/JS/Wasm tests register a provider first, so every packed-matmul test in the tree — including the ones written for #973, #1096 and #1108 — validated a configuration that was not the broken one.

A design correction inside the work. #1114 collapsed two facts into one: WeightOrientation is about the shape label, WeightByteOrder about block placement, and they are orthogonal. #1115 added the missing axis. Separately, wanting feed order (a fact about the kernel) and being able to produce it (a fact about the loader) also had to be split, after the resolver handed the loader a form it had to reject.

The through-line: bytes have to be able to say what they are. A packed weight that cannot declare its block order means one array means different things to different readers — that was #1124's wrong answers and it was what blocked KERNEL_FEED. Once declared, the kernels and the decoders are both right about the same bytes, and the per-weight relayout from #1096 stops running at all for a weight the loader pre-ordered.

Still in flight

#1128 makes MOBILE_2GB strict by default — a policy follow-on rather than part of this issue's scope.