Hi @teonbrooks, Status Update: This PR is now ready for your review!

As the first step in my GSoC roadmap, this PR successfully introduces the core JupyterLite infrastructure to the MNE-Python documentation. Here is what has been achieved:

• Integrated jupyterlite-sphinx to automatically build interactive JupyterLite instances for the examples/tutorials.
• Added a GitHub Actions CI/CD workflow to build and deploy the JupyterLite site.
• Patched MNEBrowseFigure by fixing the pyodide_plt_show argument signature to accept multiple positional arguments.
• Fixed an extension execution race condition in doc/conf.py to ensure JupyterLite successfully bundles the generated notebooks during the Sphinx build-finished event.

I also looked deeply into the [Errno 26] Operation in progress error we hit during the 10_overview tutorial. It turns out this is a fundamental limitation with Pyodide and JupyterLite. The 10_overview tutorial uses mne.datasets.sample.data_path() to download a 1.45 GB dataset from osf.io. First, osf.io has strict CORS headers that completely block browser-based WebAssembly fetches. Second, even if we were able to bypass the CORS restrictions, downloading a 1.45 GB file directly into browser RAM via Pyodide causes the browser tab to instantly crash with an Out-Of-Memory error.

To gracefully handle this and prevent user confusion, I've written a custom pooch.Pooch.fetch interceptor in our doc/conf.py configuration. Now, whenever a JupyterLite user tries to download these massive OSF datasets natively in the browser, it intercepts the request and prints a polite error message advising them to download the dataset locally and upload it directly into the JupyterLite file browser!

For smaller datasets that are CORS-friendly, it automatically falls back to Pyodide's native pyfetch via urllib so they work seamlessly without any patching needed in the tutorial code itself.

I think this is the best architectural approach for handling the massive tutorials. I'm ready to mark this PR as complete so we can move down the GSoC checklist and start tackling xeus-python and the 3D PyVista rendering! Let me know what you think! Looking forward to your feedback!

Quick Follow-up:
I also tracked down and fixed the bug that prevented the notebooks from loading correctly in the JupyterLite UI.

It turned out to be a race condition during the Sphinx build-finished event—jupyterlite_sphinx was executing before sphinx_gallery had finished generating the example notebooks. I've reordered the extensions in conf.py so they execute in the correct sequence, and all the notebooks are now successfully populating!

Updated breakdown of the split, since the pieces divided a bit differently than I first described.

• ENH: add the lite_data dataset (JupyterLite split 1/5) #14128 the lite_data dataset
• ENH: build the dev MNE wheel for JupyterLite (JupyterLite split 2/5) #14135 the wheel build and its CI step
• ENH: add a vtk.js backend for MNE's 3D renderer (JupyterLite split 3/5) #14144 the vtk.js 3D renderer
• ENH: add the JupyterLite notebook setup cell (JupyterLite split 4/5) #14150 the notebook setup cell
• last: the Sphinx wiring and the "Open in JupyterLite" badges

The renderer and the setup cell are separate because the setup cell appends the
renderer, so that one goes first. The last PR depends on all four, so it lands
last rather than in any order.

All five are up now.

#14128 the lite_data dataset
#14135 the wheel build and its CI step
#14144 the vtk.js 3D renderer
#14150 the notebook setup cell
#14157 the Sphinx wiring and the "Open in JupyterLite" badges

#14157 is red on build_docs until the earlier parts land, since it calls lite_data from #14128 and imports from #14135 and #14150. Everything else is green across all five.

I will close this one once they are merged.