feat(plan): price the resolved weight form, so a dequantization is a table line

[michalharakal]

Closes #1116. Slice 3 of 5 for #1109.

The failure this closes

MemoryPlans.plan summed PlanTensor.bytes — what the file holds. When a weight is going to be dequantized at load, that is the wrong number, and wrong in the dangerous direction:

budget checked against Q4_K packed size  →  "✔ fits"
load dequantizes to FP32                 →  4× the bytes  →  OOM

The plan now sums residentBytes — what the resolved WeightForm will actually occupy — and keeps the stored total beside it so the difference is reportable.

Where the difference surfaces

• The weights line: re-encoded at load (+3.0 GB) instead of Mapped, packed. A plan with nothing re-encoded renders exactly as it did before.
• The fit check: fails in the planner, before the load, instead of in the allocator during it.
• The suggestions: named first, because unlike --ctx or the KV mode this cost was never asked for — it is what the resolver chose when no kernel on the target could feed the stored encoding. The suggestion is "a build with kernels for the stored encoding", saving exactly what the conversion costs.

The CLI switch, and why it is a switch

PlanInput.resolveWeightForms(profile, capabilities) is the entry point. skainet-plan gains --kernels all|dense.

Two reasons it is asked for rather than detected. skainet-plan does not depend on skainet-backend-api, so RegistryKernelCapabilities is out of reach — but more to the point, the planner plans for a target device, which is not the machine running the planner. Detecting the host's kernels would answer the wrong question.

The alternative — giving the planner its own table of which encodings SKaiNET's CPU backend ships kernels for — is exactly the duplicated capability table #1114 argued against, and it would drift. So --kernels dense answers "what does this model cost on a device with no packed kernels?", and the default all leaves every existing plan byte-identical.

Tests

Seven, including the failure above stated directly: the same weight, the same budget, fits == true as stored and fits == false once a DequantizeTo(FP32) form is resolved. Plus Q4_K → FP32 being ~8×, the conversion total, the suggestion saving what it costs, and the rendered table both showing the conversion and not mentioning it when there is none.

One acceptance item had nothing behind it

The issue asked for updated "golden JSON plans for the reference GGUFs". There are none in the repository — that line referenced something never built. Nothing to update; saying so rather than quietly dropping it.

Gate

scripts/pr-gate.sh — all legs passed. (First run failed the native leg: two of my test names contained commas, which Kotlin/Native rejects in backticked identifiers and the JVM accepts. Renamed.)

🤖 Generated with Claude Code

[github-actions]

📖 Documentation Preview

The documentation has been built successfully for this PR.

Generated Files:

• Operator documentation: docs/modules/operators/_generated_/
• JSON schema output: operators.json

Artifacts:

• Download the documentation-preview-1122 artifact to view the complete documentation locally.

This comment will be updated automatically when the PR is updated.