Standardize isolated `dandi` usage (tests + runtime) to avoid dependency conflicts

[calvinchai]

Background
We have two related changes: a pytest fixture that uses dandi to download test data, and a separate PR #51 introducing dandi in normal/runtime code. dandi’s dependencies conflict with the environment if installed directly.

Proposal
Introduce a shared helper for isolated dandi invocation. Possible implementations include:

• pipx run (lightweight, recommended starter) to execute dandi without polluting deps.
• Dedicated virtualenv (e.g., under .venvs/dandi_env) with dandi installed and invoked from there.

The helper should encapsulate bootstrapping, version pinning, invocation, and error reporting. Both the test fixture and runtime code should use it.

CI Changes
Ensure the chosen isolation method is set up in GitHub Actions (e.g., install/configure pipx or create the venv) and cache its state for speed.

Acceptance Criteria

• Shared helper exists for isolated dandi CLI use.
• Test fixture uses it to download data when missing.
• Runtime PR uses the same helper instead of direct dandi dependency.
• CI workflow bootstraps and caches the isolation layer.
• Documentation or README briefly explains the pattern.
• Failures surface clear diagnostics.

Note
Start with pipx for simplicity; the backend can be swapped later behind the same interface if needed.