Optimize Shinylive loading, favicon and one.com deployment

[CedricHermansBIT]

Summary

• Keep all 110 original scientific reference distributions, but serve them separately for thin Shinylive exports. Fetch only the requested files, validate them against the per-export MD5 manifest, and cache them within the session.
• Add a small RamplotR φ/ψ favicon to the regular Shiny app and browser export.
• Load the full Plotly library only on demand (Analyse click or a plot request); retain its WebGL comparison support.
• Add optional directory-scoped one.com Apache .htaccess templates for Brotli/gzip and conservative caching, included by the export script. The site's root .htaccess remains untouched; the shared Shinylive configuration is never overwritten if it exists.
• Update README with the browser app, reproducible export command and optional XML support; add a detailed Shinylive and one.com deployment guide.
• Run new lazy-loader/reference regression tests plus existing scientific, UI and structure validation workflows.

Export from the repo root

Rscript scripts/export-shinylive.R bikc.be https://bikc.be/RamplotR/reference-data

Upload the contents of the generated bikc.be/ folder to the one.com site root, including RamplotR/reference-data/ and the shared shinylive/ assets. If one.com disallows an Apache directive, remove the generated .htaccess files; the app does not require them to function.

The native/Shiny server app and CLI continue reading the original local reference files. xml2 remains optional for ordinary structure analysis and is required to import official wwPDB XML. Live static-browser export performance and support for the optional XML feature should be checked after deployment; current CI covers native R and Shiny browser workflows.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.