Unit tests in biojava-structure depend on data.rcsb.org, and it 502s often enough to cost re-runs #1146

#1137 moved the integration tests to a nightly run so that third-party outages stop blocking pull requests. That fixed the large case. This is the residue: several tests in biojava-structure — a unit module, run on every pull request — still reach data.rcsb.org directly.

Two examples from a single evening, 2026-08-26:

#1134  AtomCacheTest.testGetStructureForDomain2
       502 for https://data.rcsb.org/rest/v1/holdings/status/1I3O
       run 33010700441

#1144  PDBStatusTest.testGetCurrent
       502 for https://data.rcsb.org/rest/v1/holdings/status/3HHB
       run 33019289062

Both cleared on a re-run with no code change. Both times the other four matrix jobs passed against the same endpoint — so this is an intermittent 502 rather than an outage, and a five-way matrix is very good at catching those. Two unrelated pull requests, two red checks, two manual re-runs.

Why this is worth a small fix rather than a shrug

They share one call site: the holdings-status lookup in PDBStatus. Stubbing or caching that single call would take both tests offline at once, without moving whole classes to the nightly — which would hide the coupling rather than remove it.

There is also a subtler variant, found in #1145: a test can look offline and not be. CathInstallationTest feeds a StringReader to the parser, then reads the result back through getDomainByCathId, which internally downloads the real CATH domain list. It passed on Linux only because the download did not finish in time.

That is the failure mode worth naming: a network dependency hidden behind an accessor, where the test appears self-contained and its pass or failure depends on how fast a third party responds.

Proposed

1. Survey which tests in the unit modules open a socket, and to which services. I am happy to do this and post the list.
2. For each: stub or fixture it if it is a unit test, or move it to biojava-integrationtest if it genuinely tests the integration.
3. Consider a build-time guard so a new network call in a unit module is noticed when it is added rather than the next time the service has a bad minute.

Point 3 is the one I am least sure about — it may be more machinery than the problem deserves. Points 1 and 2 seem clearly worth doing.

Relates to #910 and #1137.