fix(memory,kernel): serve dense FP32 mapped/off-heap storage, not just Heap

[michalharakal]

Summary

Closes #1217.

Found via a real Gemma 4 GGUF's per_layer_model_proj.weight (PLE context projection,
dequantized to FP32 at load, SegmentStorage-backed under MemorySegmentTensorDataFactory —
the construction SKaiNET-transformers' Gemma4ChatModel/KLlamaJava both use) through
Gemma4ChatModel.fromGguf. Two separate bugs stacked on the same weight:

1. TensorView.readDense (the reference-kernel decode path) only handled Storage.Heap —
   everything else threw UnsupportedOperationException, despite the class's own doc comment
   promising get() is correct for every format/storage. NarrowFloatDecoder.decodeAt had the
   identical gap for the FP16/BF16 sibling path.
2. Fp32ViewMatmulKernel (the dense-FP32 kernel KernelPacks.install() registers) also
   required Storage.Heap on every operand and silently fell back to the (now-correct-but-still
   per-element-decoding) reference kernel otherwise — so even after fixing (1), the matmul ran
   ~1000x slower than it should, never reaching a real kernel.

Fix

• TensorView.readDense: non-Heap fallback via Storage.copyInto (FP32/FP64/BF16/FP16-defensive)
  — the primitive every storage kind (SegmentStorage, MappedFileStorage, …) already implements
  uniformly.
• NarrowFloatDecoder.decodeAt: same bridge for the 16-bit narrow-float path.
• Fp32ViewMatmulKernel.run(): bridges non-Heap a/b via one bulk copyInto snapshot per
  call (not per-element) before calling the existing heap-based SPI Fp32MatmulKernel — the same
  cost class FfmRowMajorMatmulKernel (the packed-encoding sibling) already uses for its
  heap-ByteArray staging path.

Test plan

• :skainet-lang:skainet-lang-core:jvmTest — new tests: dense FP32 + narrow-float decode over
  SegmentStorage/MappedFileStorage in JvmStorageTest.
• :skainet-backends:skainet-backend-api:jvmTest — new KernelPacksSegmentStorageTest:
  confirms the pack kernel (not reference) now serves a Segment-backed weight and activation.
• :skainet-backends:skainet-backend-cpu:jvmTest, :skainet-backends:skainet-backend-native-cpu:jvmTest
  — full existing suites green, no regressions.
• Rebased onto develop post-feat(#1193): derive mapped-serving encodings from kernel registrations #1215/docs(architecture): add missing building blocks (kernel dispatch, ternary, AOT) #1216 (mapped-serving encoding derivation) — no overlap,
  both still green together.
• Real Gemma 4 E2B GGUF end-to-end completion timing — confirmed past the crash point and
  dispatching to the real kernel; full forward-pass wall-clock not yet measured to completion
  (interrupted twice mid-run in the downstream repo, unrelated to correctness here).

🤖 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-1218 artifact to view the complete documentation locally.

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