Fetch the exoplanet and mass-radius data through fwl-io

[timlichtenberg]

Description

Starts moving PROTEUS data provisioning onto fwl-io, the ecosystem data package that MORS already consumes. Relates to #605.

Today a dataset is fetched as a whole Zenodo record with no pinned version, and its files are verified only when a checksum manifest happens to be available. fwl-io pins a dataset to a Zenodo version DOI, verifies every file against a registry committed next to the manifest, and places it in a directory named for the record, so a re-pinned deposit lands beside its predecessor instead of overwriting it.

This is the first of several steps. It moves two datasets, the DACE exoplanet catalogue and the Zeng-2019 mass-radius relations, and leaves everything else on the existing downloader. I picked those two because they are read by one plotting module and carry no physics, so the manifest, the registries, the entry point and the packaging all get exercised before anything a simulation depends on moves.

What is in it:

• src/proteus/data/: a manifest declaring both datasets with their version DOIs, the two committed registries generated by fwl-io sync, and the helpers that resolve and fetch a declared dataset.
• The manifest is exposed through the fwl_io.manifests entry point, so fwl-io fetch proteus works without importing PROTEUS.
• The population diagram resolves its data directory from the pin instead of joining a path, and both datasets keep their warn-and-skip contract when the data is missing or cannot be fetched.
• The two records are removed from the legacy source map, so each dataset is pinned in exactly one place.
• src/proteus/data and tests/data are re-included in git: the run-output rule matches a data/ directory at any depth, which would otherwise have left the manifest and its registries untracked.

Two things worth flagging for review:

• The retry claim. The retry and backoff in fwl-io are not in a release yet, only on main, so against the floor this PR declares (fwl-io>=26.7.22) these two datasets get one attempt at one mirror, where the old path retried three times and could fall back to OSF. That is why the docs here do not claim retry. It is acceptable for two decorative overlays whose absence skips a plot, and it argues for cutting an fwl-io release before anything a run depends on migrates.
• Users re-download once. The data moves to a new location, so the first run after this fetches both datasets again (about 1 MB). The old copies are not read and can be deleted; the docs say so.

Validation of changes

Tested on macOS with Python 3.12.

• Fetched both datasets for real into a scratch FWL_DATA: they land in observe/exoplanet_reference/r15727878 and observe/mass_radius/zeng_2019/r15727899, and every file verifies against the committed registry.
• Built a wheel and inspected it: the manifest and both registries are inside, and the entry point is registered. This is now an integration test rather than a one-off check, because declaring package data does not prove the artifact carries it.
• Confirmed a failed fetch cannot stop a run: a download failure and an offline tree are both reported and the run continues, and the interior tables that are fetched after the overlays still arrive.
• Full unit suite passes (2714 passed, 11 skipped), ruff check clean, bash tools/validate_test_structure.sh clean, and the test-quality lint improved (single-assert count 11 to 7).
• New tests cover the manifest contents and derived locations, the committed checksums, entry-point discovery, the versioned path (pinned literally, with the bare path ruled out), the caller-supplied data root reaching the fetcher, an fwl-io too old to read the manifest being named as the stale side, the one-pin invariant against the legacy map, and the plot skipping when a dataset cannot be resolved at all.

Checklist

• I have followed the contributing guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my code
• My changes generate no new warnings or errors
• I have checked that the tests still pass on my computer
• I have updated the docs, as appropriate
• I have added tests for these changes, as appropriate
• I have checked that all dependencies have been updated, as required

[codecov]

Codecov Report

❌ Patch coverage is 97.05882% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.71%. Comparing base (e2fbd35) to head (9444a6a).

Files with missing lines	Patch %	Lines
src/proteus/data/__init__.py	94.59%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #782      +/-   ##
==========================================
+ Coverage   92.68%   92.71%   +0.03%     
==========================================
  Files         110      111       +1     
  Lines       15833    15888      +55     
  Branches     2850     2850              
==========================================
+ Hits        14675    14731      +56     
+ Misses       1158     1157       -1     

Flag	Coverage Δ
unit-tests	84.01% <97.05%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.