Add redirects for renamed locus and criTRia IDs

[hdashnow]

Description

Renamed loci and criTRia curations currently leave broken links. This matters more now that other resources (gnomAD, the UCSC genome browser) link to STRchive pages. This PR keeps old IDs in the data and uses them to generate permanent (301) redirects, and adds a check so future renames don't break links.

Fixes: #527

Major Changes

• New previous_ids field on loci: former IDs for the locus or its criTRia curation. Filled for the 10 loci renamed so far:

  Old ID	Current ID
  OPDM_ABCD3	OPDM5_ABCD3
  PLIN4_MRUPAV	MRUPAV_PLIN4
  pre-MIR7-2_CHNG3, MIR7-2_CHNG3	CHNG3_MIR7-2
  XLMR_SOX3	XLID_SOX3
  SCA_THAP11	SCA51_THAP11
  OPDM4_RILPL4	OPDM4_RILPL1
  FRA7A_ZNF13	FRA7A_ZNF713
  HFG_HOXA13-1	HFG_HOXA13-I
  OPMD	OPMD_PABPN1
  RAME8_RAI1	FAME8_RAI1

• Netlify 301 redirects are generated from previous_ids at build time (site/redirects.mjs writes dist/_redirects). Each old ID redirects /loci/OLD, /loci/OLD/* (e.g. the edit page), and /critria/OLD if the locus has a curation.

• New PR check (scripts/check-redirects.py, run by the check-redirects workflow):

  • fails if a locus or criTRia ID is removed or renamed without being added to previous_ids
  • fails if a previous ID clashes with a current ID or is listed for two loci
  • lists the redirects each PR adds in the run summary
  • warns about criTRia curations whose Locus_ID matches no locus (currently FXTAS,POF1_FMR1 and OPML1_NUTM2B_AS1)
  • Redirects for the old static site (live May–Nov 2024): /database/<GENE>.html → the gene's locus page (or /loci for genes with several loci), plus /about.html, /contribute.html, /resources.html, /plots.html (→ /loci#plots), /table.html and /index.html

Minor Changes

• Locus edit form: renaming a locus now updates the existing locus instead of adding a new one, and records the old ID in previous_ids.
• previous_ids added to check-loci.py list fields.

Notes for reviewers

• After this merges, the mondo PR will fail the new check until SD5_HOXD13 (→ SPD1_HOXD13) and OPML1_NUTM2B_AS1 (→ OPML1_NUTM2B-AS1) are added to previous_ids.
• On the deploy preview, please check:
  • the deploy log reports ~119 redirect rules processed
  • an old URL, e.g. /loci/XLMR_SOX3, returns a 301 to /loci/XLID_SOX3, with and without a trailing slash
  • The warning messages wont appear in this PR. Will need to look out for them in the next PR after this is merged.

Checklist

• All changes are well summarized
• Check all tests pass
• Check that the website preview looks good
• Update the STRchive version in CITATION.cff, format X.Y.Z. If any major changes, increment Y. If only minor changes, increment Z. If the breaking change (rare), increment X.
• Ask someone to review this PR

🤖 Co-authored with Claude Code

[netlify]

✅ Deploy Preview for strchive ready!

Name	Link
🔨 Latest commit	afc3758
🔍 Latest deploy log	https://app.netlify.com/projects/strchive/deploys/6ac1426ad128270008514fe7
😎 Deploy Preview	https://deploy-preview-528--strchive.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[vincerubinetti]

My first thought was to do something like this, but are you sure this is the right way to go? To me, this sort of defeats the purpose of having the loci tracked in git. Git already gives you the previous history of everything, and this feels like a duplication of that. Also, the primary purpose of this seems to be for the website, so it feels like leaking irrelevant implementation details of the website into the actual data.

[hdashnow]

I figured it was analogous to genes having previous IDs listed e.g. Alternative titles; symbols in https://omim.org/entry/615813

Although, to be fair, the changes in STRchive are a mix of typos e.g.
"RAME8_RAI1" -> "FAME8_RAI1"

And real name change decisions when we report a disease before it is officially named, so switch from a generic name to a specific one:
"OPDM_ABCD3" -> "OPDM5_ABCD3"

Totally open to other suggestions.

[vincerubinetti]

I can take a closer look at this on Monday and we can discuss, but my idea was something like this:

An update-redirects.yaml workflow runs on any PR that changes the loci json. For simplicity and robustness, we take a "brute force" approach that rebuilds all of the redirects (unless we find that this just takes too long). A python or typescript script runs. It goes through all of the git history for the loci json and looks for line changes that start with "id": ". For each line change, it records that A got renamed to B. Now we have a theoretical history chain for each ID, e.g. A->B->C->D. Now we start the [[redirects]] section in netlify.toml from scratch (but leave the rest of the file alone; we might need to use it to manually configure other netlify settings). We make redirect entries from A->D, B->D, and C->D. We then use a github action to add and commit the updated netlify.toml to the PR. No extra check needed, if the script works properly.