fix/ue112-rml-materials: RML import and material tables

[Atraxus]

Type of Change

• Bug fix (non breaking change, fixing an issue)
• New feature
• Breaking change (fix or feature that causes existing functionality to not work as expected)
• Documentation / Wiki update

Description

RAYX couldn't trace the UE112PGM1 beamline, and the causes mostly produced wrong numbers rather than errors. RML import ignored reflectivityType=0 and read leftover coating parameters anyway, sending an ideal mirror to the tracer as a multilayer — the failure that stopped the trace — and cast RAY-UI's integer enums straight into RAYX's, so a file requesting three discrete energies traced as a Gaussian; .DAT sampling now matches RAY-UI's nearest-node binning, checked against their source. Underneath, the material tables were broadly unsound: NFF tables were parsed but never populated, the Cromer conversion indexed mass and density by array position rather than atomic number so every element used its neighbour's values, molecule tables misread both header length and record size, and every table extrapolated past its measured range. Adds a pre-trace check that substitutes ideal geometric behaviour, with a warning, when an element's materials don't cover the source energy range. 132/132 tests; per-commit rationale in fixes-review.md. Known limits: the coverage check unions all sources and applies that to every element, skips RayListSource, and uses a ±5σ window for SoftEdge; image-plane looping and paraboloid positioning remain open and untouched.

---

✅ Pre-Merge Checklist

Important

By requesting a review, you confirm this PR is complete from your side. Once approved, it may be merged by someone else. Both developers and reviewers must ensure the PR is truly ready for merge when all checks are green.

Please complete each item before requesting a review.

• Code follows the project's coding standards
• Unit tests for new functionality are added and pass
• All existing tests pass
• Resolved TODO Comments (prefer new issues instead)
• Documentation, if applicable, including:
  • Doxygen comments for any new rayx-core API functions
  • Helpful inline comments where needed for clarity
  • Wiki pages, e.g. updated build instructions, new Element etc.
• Commits:
  • Use clear and readable commit messages (e.g. Conventional commits)
  • Squash and rebase onto master if individual commits don’t add value
  • Ensure linear commit history (required by master)