[WASM] SChunk.__getitem__/get_slice raises RuntimeError on Pyodide 0.29.4 (works on 0.29.3 and 314.0.0)

[FrancescAlted]

Summary

On the WASM/Pyodide build, slicing an in-memory SChunk that was loaded from
a frame fails with RuntimeError: Error while getting the slice — but only
under Pyodide 0.29.4. The same code passes on Pyodide 0.29.3 (cp313) and
314.0.0 (cp314).

The wheel tag is pyemscripten_2025_0_wasm32 (ABI-level), so a wheel built/tested
against 0.29.3 still runs on a user's 0.29.4 runtime — meaning this is a genuine
runtime failure for 0.29.4 users, not just a CI artifact.

Reproducer

tests/test_open.py::test_load_schunk_returns_in_memory_copy:

urlpath = tmp_path / "schunk.b2frame"
data = np.arange(20, dtype=np.int32)
blosc2.SChunk(data=data, urlpath=urlpath, mode="w",
              cparams={"typesize": data.dtype.itemsize})
loaded = blosc2.load(urlpath)          # in-memory copy, urlpath is None
assert loaded[:] == data.tobytes()     # <-- RuntimeError here

Traceback

schunk.py:1114 getitem -> get_slice(item.start, item.stop)
schunk.py:1058 get_slice -> super().get_slice(start, stop, out)
blosc2_ext.pyx:2058 -> RuntimeError: Error while getting the slice

Environment matrix

│        Python / ABI         │ Pyodide │     Result      │
│ cp313 / pyemscripten_2025_0 │ 0.29.3  │ ✅ pass         │
│ cp313 / pyemscripten_2025_0 │ 0.29.4  │ ❌ RuntimeError │
│ cp314 / pyemscripten_2026_0 │ 314.0.0 │ ✅ pass         │

Current workaround

.github/workflows/cibuildwheels.yml pins CIBW_PYODIDE_VERSION: 0.29.3 for the
cp313 wasm job (cibuildwheel 4.1's default is 0.29.4). This keeps CI green and
matches the wheels wasm.yml already ships, but does not fix the runtime for
0.29.4 users.

[FrancescAlted]

Corrected diagnosis: This is NOT a 0.29.3 → 0.29.4 regression. The failure
tracks the Emscripten toolchain, not the Pyodide patch level:

| Python | Pyodide | result |
| ------ | ------- | ------ |
| cp313  | 0.29.3  | ❌ RuntimeError |
| cp313  | 0.29.4  | ❌ RuntimeError |
| cp314  | 314.0.0 | ✅ pass |
| native CPython | — | ✅ pass |

Pyodide 0.29.x ships an older Emscripten; Pyodide 314 a much newer one. The same
compiled C source passes natively and on the newer toolchain, so this is almost
certainly an Emscripten codegen/UB issue in the 0.29.x line, exercised by
load() (frame → in-memory SChunk) followed by get_slice.

Status: tests/test_open.py::test_load_schunk_returns_in_memory_copy is now
xfail(strict=False) on WASM (xpasses on cp314). cp313 wheels ship with this as
a known limitation.