[Bughunt Phase 5] Decide the fate of stale language bindings (Java/Matlab/R, untouched since 2022) and triage related open issues

[grzanka]

Found during a full bughunt/architecture review. Unlike #290–#294, this phase is primarily a maintainer decision rather than an engineering task — filing it so the decision is tracked and the affected issues are cross-linked.

Binding staleness, verified via git log

Java:       last touched 2022-12-07
Matlab:     last touched 2022-12-07
R:          last touched 2022-12-07
Python:     last touched 2022-12-07
Linux(deb): last touched 2022-12-07
JavaScript: last touched 2024-08-20

• Java: distributions/Java/webstart/*.jnlp ships Java Web Start launch files. Web Start was removed from the JDK in Java 11 (2018) and dropped from all major browsers years ago — this binding cannot currently be used as documented.
• Matlab: no CI coverage, no verification it still builds against current MATLAB/mex toolchains.
• R: the package was removed from CRAN on 2019-09-03 (already stated candidly in README.md), yet distributions/R/generator is still a live git submodule (.gitmodules) being fetched on every full clone, and libamtrack R package installation fails #90 ("libamtrack R package installation fails") has been open since 2020 with no resolution.
• Python (pyamtrack): more actively maintained than the others per the website docs, but missing port of pyamtrack for MacOSX #216 ("missing port of pyamtrack for MacOSX") has been open since 2023.

Carrying these as if they were supported implies a support burden that, per the commit history, isn't actually being met — that's arguably worse for users than clearly marking them unmaintained.

Proposed decision (pick one per binding, doesn't have to be uniform)

• Java: given Web Start's removal from all runtimes, either replace the distribution mechanism entirely (plain JAR + runme.java, dropping webstart/) or move to contrib//mark unmaintained
• Matlab: add a minimal CI smoke build, or mark unmaintained
• R: given the CRAN removal was over 6 years ago and libamtrack R package installation fails #90 is unresolved, mark unmaintained and drop the ReGenerator submodule dependency from routine clones (it currently costs every contributor a submodule fetch for a binding that doesn't install)
• JavaScript/WASM: most actively touched of the group and has CI coverage (webassembly-reusable.yml) — no action needed here beyond the generation-tooling item below

WASM export-list generation is fragile

distributions/JavaScript/parse_headers.py builds the exported-symbol list for compile_to_js.sh by splitting header lines on whitespace and checking split_line[0] in ["int","double","long","void"] — a formatting change from clang-format (which pre-commit already runs against these same headers, per .pre-commit-config.yaml) could silently change what gets exported, with no build failure to flag it. Currently only 64 of 382 public functions are exported, from a hand-maintained list inside compile_to_js.sh. This script also appears to be unused already (see #155, "Fix javascript generation script", open since 2021).

• Replace the whitespace-splitting parser with a real C parser (pycparser or a libclang-based script) driven directly off include/*.h, or retire parse_headers.py if Fix javascript generation script #155 means it's already dead, and document which of the two (compile_to_js.sh's inline list vs. parse_headers.py) is actually the source of truth

Cross-reference: open issues now diagnosable from this review

For the maintainer's triage convenience, these existing open issues have a concrete root cause identified during this review:

• GCC 16 not compiling #287 (GCC 16 not compiling) → root cause and fix identified in [Bughunt Phase 0] Critical correctness & build blockers: wrong-function Vavilov FWHM bug, tagless/tarball build failure, SPISS never returns results #290, item 1 (same line as the Vavilov FWHM bug)
• check legal issues with numerical recipes #97 (Numerical Recipes legal check) → concrete replacement plan (GSL equivalents already available) in [Bughunt Phase 3] Architectural risk reduction: 1.15MB zero-filled RDD table, GPL-incompatible Numerical Recipes code, no error channel #293, item 2
• Remove unnecessary items from header files #57 (remove unnecessary header items) → the 1.37MB zero-filled AT_RDD_Tabulated.h table identified in [Bughunt Phase 3] Architectural risk reduction: 1.15MB zero-filled RDD table, GPL-incompatible Numerical Recipes code, no error channel #293, item 1 is the single largest offender
• Include manual of PDF in the release files #124 (include manual PDF in releases) → CI step proposed in [Bughunt Phase 4] Documentation rebuild: chatbot artifacts in README, dead autotools guide, no published API reference #294
• Extend documentation of RDD models  #125 (extend RDD model documentation) → quantified gap (93 empty Doxygen bodies, worst in AT_RDD_* headers) in [Bughunt Phase 4] Documentation rebuild: chatbot artifacts in README, dead autotools guide, no published API reference #294
• Fix javascript generation script #155 (fix JavaScript generation script) → context and a concrete replacement approach above
• Add in readme link to main documentation website #268 (link docs site from README) → folded into the README rewrite in [Bughunt Phase 4] Documentation rebuild: chatbot artifacts in README, dead autotools guide, no published API reference #294
• Fix windows binaries, currently examples are not producing any output #258 (Windows examples don't run) → CI fix proposed in [Bughunt Phase 1] CI cannot currently fail on a correctness regression: no assertions, no sanitizer job, no warning budget #291
• Negative values in dose-fluence and fluence-dose calculations using ICRU as a source and air as a material #278 (negative dose-fluence values with ICRU/air) → not diagnosed by this review; flagging that it deserves a dedicated investigation once the Phase 1 ([Bughunt Phase 1] CI cannot currently fail on a correctness regression: no assertions, no sanitizer job, no warning budget #291) test harness exists, since it's an unexplained physics discrepancy rather than an obvious code defect
• AT_single_impact_local_dose_distrib() is partially unclear #161 (AT_single_impact_local_dose_distrib() partially unclear) → likely addressed as a side effect of the documentation burn-down in [Bughunt Phase 4] Documentation rebuild: chatbot artifacts in README, dead autotools guide, no published API reference #294

Acceptance criteria

• Each binding in distributions/ has an explicit, documented maintenance status (maintained / unmaintained / removed)
• The WASM export list has a single documented source of truth
• Cross-referenced issues above are either closed as duplicates/resolved by the phase work, or explicitly kept open with an updated description reflecting the new context

Related: #90, #97, #124, #125, #155, #216, #258, #268, #278, #287, #57, #161