[michalharakal]

Summary

Sixth step of the JVM ↔ wasm parity series (after #1363, #1364, #1368, #1369, #1426), and the IO half of it: the places where a browser build could not load what a JVM loads, closed where the platform allows and named as an explicit N/A with its reason where it does not.

JsBlobRandomAccessSource (Kotlin/Wasm, skainet-io-core) — the RandomAccessSource over a browser Blob:

• Long positions and size. Blob.slice takes JavaScript numbers (53 bits); the source addressed it through Int, so a Blob over 2 GB — one shard of a sharded checkpoint, routinely — truncated its positions. The Kotlin/JS variant gets the same fix and a copy-free ByteArray view (Int8Array is a ByteArray there).
• Bulk copies. Bytes reach Kotlin through wasm linear memory, one Uint8Array.set per 4 MB stage and a wasm loop into the ByteArray, instead of one interop call per byte (fifty million of them for the default 50 MB preload).
• Blocking reads beyond the preloaded window. Inside a Web Worker the Blob is read synchronously through FileReaderSync, so the streaming readers (StreamingSafeTensorsReader, StreamingGGUFReader) load a whole model from a Blob through the same blocking code path the JVM takes over a file. supportsSyncReads says which thread the source is on, openSync opens without preloading for worker code outside a coroutine, and a blocking read beyond the window on the main thread throws with that explanation instead of blocking the page. The suspending read() works everywhere, as before.

Sharded SafeTensors without a file system — ShardedSafeTensorsParametersLoader(indexJson, shardSource) and StreamingShardedSafeTensorsReader.openFromIndexContent / openFromParsedIndex: the index as text and a (suspending) provider that opens each shard by file name — a Blob per shard in a browser, ByteArrayRandomAccessSource over fetched bytes — plus withPolicy for the new form. The path constructor is unchanged and delegates to the same reader, which now opens every shard exactly once (it used to open, close and reopen each) and releases what it opened when a shard is missing or fails to parse. Mapped loading needs file-backed shards and says so for Blobs.

PlannerProfile.BROWSER — the tab profile: 256 MB reserved (Budget.RESERVE_BROWSER), dense weights quantized to Q8_0 at load, KV auto-quantized past 80 %, nothing mapped; off-heap allocations go to the kernel sidecar's linear memory once WasmSimd.install() has bound it. PlannerProfile.forDevice() returns it on Kotlin/JS and Kotlin/Wasm (a tab's RAM figure says nothing about what the tab may use); BROWSER_AVAILABLE_BYTES (2 GB) is what to plan against when the host reports nothing; skainet-plan --profile browser.

MemoryProbe in a browser — a tab has no /proc, so rssBytes() on Kotlin/Wasm sums the three places SKaiNET's bytes live: the JavaScript heap in use (Chromium's performance.memory; Kotlin/Wasm objects are GC objects there), the module's own linear memory, and the bytes the installed OffHeapAllocator holds — a new heldBytes() on the hook, which the SIMD128 sidecar answers with its resident weights and activations. Kotlin/JS reports the JavaScript heap. Fault counters stay null, as the common contract allows.

Docs — how-to/io-readers.adoc gains the browser section (Blob sources, worker-side loads, sharded checkpoints from Blobs) and a per-target table listing every remaining difference with its reason: no file system (path APIs, mmap, file writers), FileReaderSync worker-only, 2 GB arrays, no Kotlin threads. The planner and memory-model pages carry the profile and the probe.

Verification

• :skainet-io:skainet-io-core:wasmJsBrowserTest — new JsBlobRandomAccessSourceTest (Chromium under Karma): size and preload, blocking reads inside the window and the explanatory failure beyond it on the main thread, suspending reads across the window edge, deep in the Blob, at its end and across two 4 MB stage boundaries byte for byte, and the worker path — FileReaderSync polyfilled for the main thread by a synchronous XMLHttpRequest on a Blob URL, so the production call site runs under Karma — including openSync.
• :skainet-io:skainet-io-safetensors:wasmJsBrowserTest — new ShardedSafeTensorsBlobTest: a two-shard checkpoint from Blobs through the provider constructor into tensors on the CPU context, on the main thread (preload) and on the worker path (nothing preloaded, blocking reads from the Blob), plus a missing shard with and without allowPartial.
• ShardedSafeTensorsReaderSourceTest (common, every target): provider asked once per shard, name-sorted tensors, metadata merged, sources closed with the reader, missing shard / corrupt shard / throwing provider with and without allowPartial, mapped loading through a source that names its file.
• ShardedSafeTensorsParametersLoaderJvmTest gains the path-vs-provider parity test (file sources and in-memory bytes). PlannerProfileTest gains the browser rules; MemoryProbeTest runs unchanged on the wasm and JS browser legs with the probe now answering. SkainetPlanTest knows browser. M2AcceptanceTest.m2a3 (backend-cpu) no longer asserts that a platform which knows its RSS knows its faults — a browser now reports the former and never the latter.
• scripts/pr-gate.sh --quick, full gate, apiDump.

Measured

Chromium under Karma (Kotlin/Wasm, 12-core laptop), an 8 MB range of a Blob:

Step	Before	After
Int8Array → ByteArray	219 ms (one interop call per byte, ~38 MB/s)	36 ms (4 MB stages through linear memory, ~230 MB/s)
Whole read() incl. blob.arrayBuffer() (16 ms)	235 ms	52 ms

For the default 50 MB preload that is roughly 1.4 s → 0.3 s before the first header byte is parsed — the old preload alone cost more than a Laya decision does after #1426. The remaining cost is the wasm loop that moves the staged bytes into the ByteArray; Kotlin/Wasm offers no bulk path into a GC array.

Not covered by a test: a Blob over 2 GB (Karma cannot hold one); the Long path is the same code with a larger number, and the JS boundary takes a Double.