Convert ros3 streaming to remfile in User Guide Part I and NWBWidget demo

[bendichter]

These are two of the five groups that failed verification in the container-image fleet rollout (see the scorecard on #180). Both opened DANDI assets with h5py's ros3 driver, which PyPI h5py wheels do not ship, so they failed in the image verification and in headless CI, and would fail for any user in a pip-installed environment. They now stream through remfile, following the pattern in docs/adding-notebooks.md, with remfile==0.1.14 added to their install cells (numpy, h5py, and requests were already pinned).

Fixing ros3 in the NWBWidget demo unmasked a second, older problem: the "Running NWBWidgets locally" section printed a download URL, instructed the reader to click it, and then opened ~/Downloads/<file>. That can never run unattended, so the ros3 failure had been hiding it. The section now downloads a 44 MB asset from the same dandiset programmatically to a temporary path and opens that, which keeps the demonstration of local-path reading intact while making the notebook runnable end to end.

Verified by building both container image groups locally and running each notebook inside its image with the CI harness: DANDI User Guide, Part I finished in 17s and NWBWidget-demo in 17s, both green. After merge, dispatching the image workflow will publish these two groups, bringing the fleet to 30 of 33.

🤖 Generated with Claude Code

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[github-actions]

Preview for this PR has been removed (PR closed).

[bendichter]

Updated per review: the remfile wrapping is split onto its own lines with remfile.DiskCache("nwb-cache") in both notebooks, and both directories now carry committed requirements files per the new contract (demos/requirements.in shared; a per-notebook DANDI User Guide, Part I.requirements.in since Part II shares the dandi/ directory with a different dependency set).

Re-locking from those files surfaced a genuine conflict worth knowing about: nwbwidgets 0.9.1 only imports on the pre-2024 stack (newer zarr removed zarr.core.Array, and newer hdmf cannot resolve its bundled ndx-spectrum spec), while a DANDI-server-compatible client needs dandi>=0.76.5, which under Colab's current click pin requires pynwb>=3.1. The two cannot coexist. Resolution: the NWBWidget demo, whose subject is the widgets and which does not use the dandi client, keeps the bounded old stack (pynwb<3, hdmf<4, zarr<3); the User Guide, whose subject is the dandi client, drops nwbwidgets and shows files via pynwb's rich Jupyter repr on the current stack (dandi 0.77.0, pynwb 4.1.0).

Both notebooks verified green end to end inside freshly built container images.