The upstream fetcher writes DOI_* on every cache miss, so #690's rename recurs

[realmarcin]

Summary

#690 was closed on the grounds that the repository's cache writer was fixed.
That was true of scripts/cache_fulltext.py and not of the fetcher that
actually fills the cache during just validate-references.
linkml-reference-validator normalises a reference id to DOI: and builds its
cache path from that, so every cache miss it fills writes DOI_*.md — recreating
the exact split that accumulated 133 files.

#690's closure was therefore incomplete. Recording it here rather than
reopening, because the repo-side half is genuinely done and the remaining half
is a dependency.

Evidence

Re-fetching six DOIs into an empty scratch directory with the current
dependency:

$ ls "$SCRATCH"
DOI_10.1007_s13213-019-01453-y.md
DOI_10.1016_j.cej.2020.124801.md
DOI_10.1029_2018JG004621.md
DOI_10.1128_aem.69.8.4853-4865.2003.md
DOI_10.1134_S0026261716060059.md
DOI_10.3390_min14030255.md

Every one uppercase, from doi:-prefixed input. The cached frontmatter shows
the normalisation:

reference_id: DOI:10.1007/s11270-011-0818-5

get_cache_path then does
reference_id.replace(":", "_").replace("/", "_") → DOI_…
(etl/reference_fetcher.py:204-225).

Seven such files were sitting in the working tree from an earlier fetch. They
are unreachable to every reader in this repository, all of which build doi_…
from the doi: citation.

Why it matters

Per src/communitymech/paths.py, a cache miss is not a skip — the fetcher goes
to the network. So each unreachable file is re-fetched on the next run, writes
another unreachable file, and the loop never converges. On Linux the file is
invisible; on macOS it is found by accident.

Guard already in place

PR #698 adds test_every_cache_filename_uses_the_canonical_prefix_casing: no
cache filename may use a prefix casing no citation resolves to. It fires as soon
as such a file exists, rather than waiting for a record to cite it — which is how
the seven in the working tree were found.

That converts a silent recurrence into a failing test. It does not stop the
fetcher creating them.

Options

1. Normalise after fetching — a wrapper around just validate-references
   that renames any DOI_* it produced. Small, local, and keeps working
   regardless of the dependency's behaviour. Renaming needs a temporary name on
   macOS (core.ignorecase=true).
2. Upstream fix — have the fetcher preserve the citation's prefix casing, or
   lowercase the prefix consistently. Correct, but not in this repository's
   control, and every checkout keeps producing the wrong names until it ships.
3. Accept both casings on read — make every reader case-insensitive. This
   was rejected once already: it makes the local and CI answers differ for
   anything that lists the directory, which is A cache-resolution fallback that could never match made a snippet gate report different results on Linux and macOS #694's failure mode.

Option 1 with option 2 filed upstream looks right. Option 3 should not be
revisited without new information.

Acceptance test

just validate-references on a record whose source is not yet cached leaves a
doi_* file, and test_every_cache_filename_uses_the_canonical_prefix_casing
passes without anyone renaming anything by hand.

[realmarcin]

Fixed in 851b39a (PR #702).

scripts/normalize_cache_names.py runs after every justfile recipe that can fetch — validate-references, validate-references-all and repair-references — each preserving the validator's exit code, so normalising can never turn a failing validation green. tests/test_cache_names_are_normalised_after_fetching.py pins both halves by parsing the recipes from just --dump; it found repair-references, which I had missed.

Option 1 from this issue. Option 3 (accept both casings on read) stays rejected: it makes local and CI answers differ, which is #694's failure mode.

Left open as follow-ups: #706 (the normaliser's own exit code is discarded, so a [conflict] cannot fail anything) and #705 (now fixed) for the interrupted-rename hole the review found.