Add reference frames (OPT, NNR, TPW, PMAG) to un-optimised rotation files

[jcannon-gplates]

Summary

Adds add_ref_frames_to_unoptimised.py, a post-processing step that assembles a
single comprehensive rotation model containing all available absolute reference frames
as distinct (high-numbered) plate IDs:

Plate ID	Reference frame
014	paleomag (the model's native frame)
015	optimised mantle (best run)
016	optimised mantle, maximum net rotation (nr_max run)
017	no-net rotation
018	approx true polar wander (TPW = pmag − optimised)

Anchoring to any of 014–018 in GPlates/pyGPlates reconstructs the model in that
reference frame; anchoring 000 uses whichever frame default_reference_frame_plate_id
is set to (paleomag by default). Reference-frame features are bundled into the first
output rotation file so plate 000 is always defined.

Key implementation details:

• All input/output paths are derived automatically from Optimised_config.py — the
  script needs no manual editing for a standard run.
• An unoptimised_input_is_in_pmag_frame guard aborts rather than silently
  mislabelling reference frames if the input is not in its paleomagnetic frame.
• Rotation sequences stored as R(000→frame) (fixed 000, moving frame) so GPlates
  does not see conflicting sequences with 000 as the moving plate.
• Adds config support for Merdith_etal_plate_model_1Ga-present_rev6-2 and fixes
  Zahirovic_etal_2022_GDJ (PMAG seeding via Africa 701701 / GAPWAP, corrected file
  paths).
• README rewritten to reflect current capabilities (laptop runtime, GPlately PMM,
  5 reference frames, updated installation and run instructions).

🤖 Generated with Claude Code

[jcannon-gplates]

Gosh, Dietmar's Claude modifications re-arranged my add_ref_frames_to_unoptimised.py script so much (including re-arranging the reference frame math) that I genuinely got confused. But I'm reasonably sure the math is still correct (eg, TPW). Not 100% sure though.

How does it re-arrange so much and still get it right! Claude probably did this in a few minutes, but it's taken me many hours to convince myself it's correct (partly because I had to reload all the work I'd done a year ago back into my mind in order to check this).

The new code is actually cleaner and better. It's just hard to compare and verify. In situations like this (and probably for any optAPM modifications) I think we need to tell Claude not to restructure source code and rotation math so much. I googled and found this:

CRITICAL: MATHEMATICAL & STRUCTURAL LAYOUT PINNING
1. PRESERVE MATH LOGIC VERBATIM: Do not alter, re-factor, or re-arrange any mathematical equations, formula sequences, or rotation logic (e.g., matrix/quaternion/trig operations). Keep the operators, variable assignments, and sequence of steps exactly as written.
2. NO CODE RE-STRUCTURING: Do not collapse, expand, or split existing blocks of logic. Treat the current script structure as immutable.
3. LINE-MATCHING EDITS ONLY: Only modify the specific lines of code required for the new feature. Do not touch adjacent structural logic "for cleanup."
4. NO INLINING: Do not inline local variables or expand existing multi-line calculations into single lines.

...probably easiest to just add directly to the chat prompt (a more permanent solution depends on whether using Claude Code or Claude Projects; eg, CLAUDE.md or custom instructions).

Also, Dietmar has been trying this out on some plate models, so would probably notice when anchoring different reference frames looks weird. So I'll go ahead and merge this. If something looks suspect in the future we can come back and revisit this.