Regenerate web package-lock.json to match installed dependencies

[maheshtank1206-maker]

Why

The lockfile changed during a dependency reinstall to address native-binding issues encountered when running the web dev server (Vite/rolldown). This PR updates the lockfile so the repository reflects the tested dependency graph.

What/approach

• Regenerated web/package-lock.json to match the installed packages after resolving install issues.
• No application source files were modified; this is a lockfile-only change.

Notes for reviewers

• No behavioral changes expected; verify CI dependency checks if any.
• If this looks unexpected, run an npm install in web/ and compare the resulting lockfile.

Migration/impact

N/A — only the lockfile changed.

[JustVugg]

Thank you for the clear write-up — the "notes for reviewers" section is exactly what made this quick to check, so let me show you what the check found rather than just declining.

The lockfile is not out of sync. npm ci succeeds against web/package.json on current dev, and the Web UI CI job — which runs npm ci && npm run build — is green on every commit. So there is no broken state here for the regeneration to repair.

And the diff does more than re-align. Two things in it are not lockfile housekeeping:

-      "version": "1.11.1",          @emnapi/core
+      "version": "2.0.0-alpha.3",

That promotes a stable dependency to an alpha release. It also adds 36 lines of nested vite/node_modules/lightningcss-* platform binaries (removing 1) — a duplicated native-binary tree under vite, which is the usual signature of an npm install that resolved bindings on one machine.

Neither is what the title describes, and I do not think you intended either — they are what npm install did while you were getting the dev server working, which is exactly the situation you described. That is the problem: a lockfile regenerated to fix one machine's native-binding issue carries that machine's resolutions to everyone, including an alpha.

So I am going to decline this one. Not for lack of usefulness — for the opposite reason, that a lockfile change is high-blast-radius and this one has effects beyond its stated purpose.

But the problem you hit is real and worth capturing. Vite/rolldown native bindings failing on a fresh checkout is a genuine setup papercut, and you are the person who has actually debugged it. If you would open an issue describing the failure — platform, node version, the error, and what you did to get past it — that is more valuable than the lockfile, because the fix might be a documented prerequisite, an engine/node version pin, or a real dependency change that we then make deliberately rather than as a side effect.

One process note for next time, not a criticism: PRs here should target dev rather than main. main is release-only and protected, so anything opened against it needs redirecting before it can move.

Closing this, with the branch still yours. Thanks for taking the time to write it up properly.