Add Pyodide support and CI jobs for Zarr

[agriyakhetarpal]

Description

This PR adds official support for running Zarr v3 via Pyodide, running in the browser via WebAssembly. I have introduced a CI job and various code changes to ensure compatibility, disable unsupported features, and adjust test infrastructure accordingly. The most important changes are grouped below.

I've provided a short summary below. AI disclosure: it was partially generated using the GitHub Copilot actions button that appears when editing the PR description. I've carefully read it and augmented it by adding some points of my own, and I've removed some points that were not particularly relevant.

WASM/Pyodide platform support

• Added an emscripten.yml workflow to run CI tests on Pyodide/WASM.
• Introduced a new constant IS_WASM in src/zarr/_constants.py to detect WASM environments, and used it throughout the codebase for platform-specific logic
• Updated zarr.core.sync to support WASM: synchronous APIs now check for JSPI availability. Thread-based event loops are disabled in WASM.
• codec_pipeline.max_workers resolves to 1 in WASM environments as we can't spawn new threads, so FusedCodecPipeline stays on its sequential path even if a larger value is set explicitly.
• _safe_move in zarr.storage._local handles file moves safely on Emscripten, as inode-based hard links are not present in its virtual file systems. I've split it up into three platform-specific methods.

Testing infrastructure and CI adjustments

• Declared a dedicated Pyodide test Hatch environment in pyproject.toml. Its pytest invocation passes -o faulthandler_timeout=0 because pytest's faulthandler watchdog needs a thread to run its timer and cannot start one under Emscripten.
• Updated test dependencies and markers to skip or adapt tests that are incompatible with WASM (e.g., subprocesses, multiprocessing, or threading).
• Monkeypatched asyncio.Runner in WASM environments to integrate with Pyodide’s native event loop, the WebLoop. This fixes two issues: (i) various ResourceWarnings appearing with consecutive async tests as a result of interactions between the pytest-asyncio private event loop and the webloop, and (ii) the webloop takes over as the running loop and thus making pytest-asyncio run coroutines on it instead of trying to run on its own.
• Unit tests are skipped entirely where certain modules from the Python standard library are not available or limited in functionality, which at the time are threading and multiprocessing (see also: Threading support pyodide/pyodide#237).

Here are some related conversations where Pyodide (and its related discussions) has come up as a topic: #536, #1018, #1019, #1104, fsspec/filesystem_spec#960, and zarr-developers/community#43

It is to be noted that this PR has been accompanied by a corresponding sister PR for Pyodide builds for numcodecs at zarr-developers/numcodecs#529, where numcodecs builds successfully and the test suite passes. The change was proposed after discussion at one of the community meetings for Zarr on March 6th, 2024 (meeting notes).

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions No user-facing features or public API were proposed
• New/modified features documented in docs/user-guide/*.rst There are no new features in this PR
• Changes documented as a new file in changes/
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

Additional context

Here are a few xrefs to some other PRs that have been implemented for packages in the Scientific Python ecosystem circa 2024:

• NumPy's Pyodide job: CI, BLD, TST: Re-enable Emscripten/Pyodide CI job for NumPy numpy/numpy#25894, by courtesy of @rgommers
• The same for PyWavelets (which is an optional dependency for scikit-image): Build and test PyWavelets Pyodide wheels in CI PyWavelets/pywt#701 and Upload dev wheels to Anaconda.org + revamp wheels publishing workflow PyWavelets/pywt#714
• For the pandas repository BLD, TST: Build and test Pyodide wheels for pandas in CI pandas-dev/pandas#57896
• Add out-of-tree Pyodide builds in CI for scikit-image scikit-image/scikit-image#7350
• and so on

As of May 2026, PEP 783 has been accepted, and wheels for the Pyodide platform, with a "pyemscripten" platform tag, are being made available via PyPI. This PR and the sister numcodecs PR I mentioned above are efforts made in this light to increase our adoption in the ecosystem. Our next release of Pyodide, v314.0.0, is coming soon, and two alphas have already been released. I can draw on the changes I've made in this PR to re-enable Zarr support after it was disabled due to the v3 upgrade in version 0.28 (pyodide/pyodide-recipes#99).

My previous (and still current, but slightly lower priority than before) long-term goal towards this change, when I opened this PR back in 2024, was to implement Sphinx-based interactive documentation via JupyterLite and WASM-powered in-browser kernels, as referenced in Quansight-Labs/czi-scientific-python-mgmt#19; see also Quansight-Labs/czi-scientific-python-mgmt#18. A pilot of this that can be readily tried out is available for the "API reference" pages under the PyWavelets documentation. This can be preceded by integrating Sphinx extensions such as jupyterlite-sphinx for hosted documentation. Nightly wheels from the Anaconda Scientific Python Nightly Wheels channel can be used for nightly/dev documentation, and hopefully pure Python wheels from PyPI with this PR included for stable versions.

[agriyakhetarpal]

Since we've now released Pyodide 314.0.0 stable, I've bumped to it and removed the TODO note. I've pinned pytest<9.1 due to a regression which is being tracked upstream: pytest-dev/pytest#14591, pytest-dev/pytest#14592.