fix(security): pin vendored model-viewer bundle to verified upstream

[superm1]

Summary

The vendored src/app/src/renderer/vendor/model-viewer.min.js had drifted from the documented upstream and carried no integrity hash, so a webpack import could not detect tampering or corruption.

This PR pins to the pristine artifact and secures it:

• Replace the bundle with the exact dist/model-viewer.min.js from the npm registry tarball for @google/model-viewer@4.3.1, verified against npm's published sha512 integrity.
• Add model-viewer.min.js.sha256 (SHA-256 283b06…) and a CI job in docs_and_style.yml that runs sha256sum -c to fail on any drift.
• Rewrite the vendor README.md to record the hash chain (npm tarball integrity → extracted-file SHA-256) and a hash-preserving update process that validates npm's dist.integrity before extraction.

Review notes

Shadow mapping fix (upstream #5168)

The locally patched 4.3.0 file contained a shadow-depth shader fix from google/model-viewer#5168 correcting the orthographic frustum and floor/blur-plane scaling for models larger than 1×1. That fix is included in the official 4.3.1 release, so the bundle is now pristine upstream with the fix intact.

"Drift guard" vs SRI

The sidecar SHA-256 check is a drift guard rather than a true SRI replacement: the file and checksum can be changed together in the same commit. The npm dist.integrity (SHA-512) is the authoritative upstream trust anchor, and the documented update process verifies it before extracting the file.

[fl0rianr]

Thanks, right direction, but not ready yet:

[fl0rianr]

Thanks, better, but not fully there yet.

[fl0rianr]

Thanks, this is much closer. I still see one blocker though: model-viewer.min.js itself is unchanged from the base branch, so the PR currently documents and hashes the existing blob as pristine 4.3.1 without actually replacing it.

Could you also make the update snippet fail closed (set -euo pipefail, ideally extract into a fresh temp dir), and change the workflow comment from “equivalent of SRI” to “drift guard” to match the README?

Once those are fixed, this looks good to me.

[fl0rianr]

Thanks, the previous points look good now. One small thing remains: please use mktemp -d for the extraction directory as well, so the update flow is fully isolated and fail-closed even after an interrupted previous run.

It would also be helpful to note that the verified 4.3.1 artifact produces the existing 283b06… SHA-256, which explains why the vendored bundle itself does not appear in the diff.

Merge conflicts, rebase or main sync is due.

With that, this looks good to me.