chore(ci): commit the frontend-core lockfile so Trivy can scan npm

[pavlo-flamingo]

Problem

The Scan Code job (Trivy) never looks at the frontend. Its log says:

INFO  Number of language-specific files  num=36
INFO  [cargo] Detecting vulnerabilities...
INFO  [pom]   Detecting vulnerabilities...

No npm analyzer — openframe-frontend-core is silently skipped. A green frontend in that report is "not scanned", not "clean".

Cause

package-lock.json was gitignored (line 48, inherited from the original UI-Kit migration in ccb885c). Trivy resolves the npm dependency tree from the lockfile; without one it has nothing to analyse. The same gap blocks npm audit, the GitHub dependency graph and Dependabot alerts.

Fix

Un-ignore the lockfile and commit it for openframe-frontend-core, generated from the current manifest with npm install --package-lock-only (1289 packages, all resolved from registry.npmjs.org, no local paths).

Second commit: install from the lockfile

npm ci in the three install steps (both node jobs in test.yml, the publish job in release.yml), the setup-node cache key moved to package-lock.json, and three comments corrected — they documented the absent lockfile as a given, including test.yml's own note that fixing this "would be a repo-wide policy call". This PR makes that call.

The npm pin working around the Arborist edgesOut crash stays: a missing lockfile is the likely trigger, but that is worth confirming over a few green runs rather than assuming.

What CI now says

Verified on this branch: Trivy's npm analyzer runs (Number of language-specific files num=37, [npm] Detecting vulnerabilities..., dir="openframe-frontend-core/node_modules"), covering the 1037 production entries of the lockfile — Trivy skips the 251 marked dev: true. It reports no npm HIGH/CRITICAL: the lockfile resolves to current patch versions, and the scan runs with --ignore-unfixed. npm ci installs cleanly (added 1126 packages), and every check after it — type-check, lint, lint:types, format, test, build, lint:cycles — is green.

Scan Code stays red on the same 92 Java/Rust findings it fails on for every PR on main. This PR neither adds to them nor fixes them.

Caveats

• Merge order. The lockfile matches openframe-frontend-core/package.json as of this branch point, and nothing on main has touched that manifest since. If a PR changing those dependencies lands first, rebase this one and regenerate the lockfile — otherwise npm ci fails on main for everyone.
• Nothing refreshes the lockfile yet. There is no .github/dependabot.yml in this repo, so pinned versions will age and Scan Code will eventually go red on npm with no automated bump path. Adding one is the natural follow-up, and it is a separate call because it affects maven and cargo too (24 open Dependabot alerts across the three ecosystems).
• react-embedding-example is left without a lockfile on purpose: it depends on @flamingo-stack/openframe-frontend-core via file:.yalc/..., which does not resolve outside a yalc-linked checkout. Its 3 open npm alerts (dev-scope vite) therefore stay outside Trivy's reach.
• pnpm-lock.yaml stays ignored — the repo installs with npm.
• Contributors changing dependencies must now commit the regenerated lockfile. npm ci on the PR job catches it before release does.