Please address the comments from this code review:

## Overall Comments
- The Zenodo URLs and SHA256 hashes are duplicated between the notebook and `scripts/zenodo_upload.py`; consider centralizing these constants (e.g., a small shared module or JSON) so future updates only need to be made in one place.
- The notebook hardcodes `DATA_DIR = Path("../data")`, which may break if the notebook is executed from a different working directory; consider resolving the path relative to the notebook file or using the same helper/path logic as your other pooch-based examples.
- In `zenodo_upload.py`, both sandbox and production use the same `ZENODO_TOKEN` env var; if you plan to use separate tokens, it might be safer to support distinct variables (e.g., `ZENODO_SANDBOX_TOKEN`) or a `--token` argument to avoid accidentally using the wrong credentials.

## Individual Comments

### Comment 1
<location path="scripts/zenodo_upload.py" line_range="125-134" />
<code_context>
+            )
+            return 3
+        with path.open("rb") as fh:
+            r = requests.put(
+                f"{bucket_url}/{remote_name}",
+                params=params,
+                data=fh,
+                timeout=None,
+            )
+        r.raise_for_status()
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Consider using a finite timeout for the file upload request instead of `timeout=None`.

An infinite timeout can cause the upload to hang forever if the connection stalls. Using a finite (possibly large) timeout, or separate connect/read timeouts, makes failures predictable and better suited for automated runs. You could also expose the timeout as a CLI option for large uploads.

Suggested implementation:

```python
            r = requests.put(
                f"{bucket_url}/{remote_name}",
                params=params,
                data=fh,
                # Use a finite timeout to avoid hanging indefinitely on stalled connections.
                # This tuple is (connect_timeout, read_timeout); adjust as appropriate.
                timeout=(10, 600),
            )

```

To fully implement the suggestion of making this timeout configurable:
1. Add a CLI option (for example `--upload-timeout`) in the argument parser to allow the user to specify either a single timeout value or a connect/read timeout pair.
2. Parse that option into either a float/int or a `(connect_timeout, read_timeout)` tuple.
3. Replace the hard-coded `(10, 600)` in the `requests.put` call with the parsed timeout value (for example, a variable like `upload_timeout` that you pass through to the function containing this code).
</issue_to_address>