Pin versions and add Subresource Integrity for CDN-loaded MathJax and Mermaid

[hash-and-salt-too]

Hi — first, thanks for QLMarkdown. This is a hardening suggestion, not a bug report.

While reviewing 1.5.0 I noticed that the MathJax and Mermaid libraries are
referenced from jsDelivr without a pinned version:

https://cdn.jsdelivr.net/npm/mathjax/es5/tex-mml-chtml.js
https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js

Without an @version, these resolve to whatever is current at fetch time.

Two consequences:

1. No integrity guarantee. There's no Subresource Integrity hash, so the
   contents can change without the app being aware. The polyfill.io incident in
   2024 showed this isn't theoretical — a widely used CDN endpoint changed hands
   and began serving malicious code.

2. Unpredictable version. Because the version floats, it's hard to say which
   library version any given install is actually running. That makes it awkward
   to reason about advisories — for example, Mermaid published several
   sanitization fixes in 2026 (CVE-2026-41148/41149/41150/41159).

Possible mitigations, roughly in order of strength:

• Bundle the libraries in the app. Strongest: the signed, notarized artifact
  then contains all the code it runs, and the whole question disappears.
• Pin a version and add an SRI hash, e.g.
  https://cdn.jsdelivr.net/npm/mermaid@11.x.y/dist/mermaid.min.js with
  integrity="sha384-...".
• Pin the version only. Weaker, but at least makes the running version knowable.

I appreciate the trade-off — bundling increases app size, and floating versions
pick up upstream fixes automatically. Entirely your call. Flagging it in case
it's useful.

[sbarex]

Implemented on release 1.5.4.

Now on the html output the mermaid and mathjax library can be:

• linked from web, with a fixed release and with the integrity hashes
• embedded in the html, using a file bundled inside the application at the compile time.