fix(deps): regenerate frontend lockfile + skip canvas postinstall to unblock prod docker build (#214)

After PR #213 fixed the multiplayer half of this deploy class, the
prod docker build moved on to a second latent failure in
`frontend/Dockerfile`'s `npm ci` step:

    npm error Missing: @csstools/css-color-parser@3.1.0 from lock file
    npm error Missing: lru-cache@10.4.3 from lock file
    npm error Missing: whatwg-url@14.2.0 from lock file
    ... (~20 more)
    target frontend: failed to solve: npm ci ... exit code: 1

Two compounding root causes:

1. `frontend/package-lock.json` was severely incomplete (299
   `node_modules/...` entries against a dep tree that actually
   resolves to ~550). Prior deploys hit the cached `RUN npm ci`
   Docker layer and never noticed; the cache invalidation from PR
   #213 forced a cold rebuild and exposed it. Local `npm install`
   in a workspaces repo can write resolutions to the ROOT lockfile
   without propagating to the standalone workspace lock — which is
   what the Dockerfile actually copies. Same shape as the issue
   PRs #205 / #207 fixed.

2. Once the lockfile is complete, `npm ci` proceeds into install
   and trips a SECOND latent issue: `vite-ssg` transitively pulls
   `canvas@2.x`, whose post-install script tries to fetch a
   pre-built `linux-musl-x64` binary that node-canvas does not
   publish (alpine = musl; node-canvas ships glibc binaries only).
   It then falls back to compile-from-source, which needs Python +
   gcc + Cairo headers we don't install in this image.

Fix:

* Regenerate `frontend/package-lock.json` from scratch via `npm
  install --package-lock-only --no-workspaces` from `frontend/`.
  Diff is large (~3000 added lines) because dozens of nested
  package trees were missing entirely, not just a few entries.
* Add `--ignore-scripts` to the frontend `npm ci` invocation. The
  frontend build never invokes canvas (no SSR happens at build
  time; the browser provides the native `<canvas>` API at runtime),
  so the package being present-without-its-binary is harmless.

Verified end-to-end with `docker build --platform linux/amd64 -f
frontend/Dockerfile .` — the same arch as the prod runner. vite
build completes in 51.57s, image tags successfully, no canvas
errors.

No source code changes. No runtime behaviour change.

Follow-up worth considering separately: `frontend/package.json`
declares `vitest@^1.6.1` and `vite@^5.1.0` — the same combination
that broke multiplayer in PR #213. Frontend doesn't have colyseus
in its dep tree so the peer conflict doesn't fire, but a future
vitest/vite upgrade is still a one-PR cleanup.

Signed-off-by: Arun Rajkumar <mickyarunr@gmail.com>

Author: mickyarun

frontend/Dockerfile

@@ -11,7 +11,16 @@ ARG VITE_API_BASE_URL=/api
 ENV VITE_API_BASE_URL=$VITE_API_BASE_URL
 
 COPY frontend/package.json frontend/package-lock.json* ./
-RUN npm ci --no-audit --no-fund
+# --ignore-scripts is required because `vite-ssg` transitively pulls
+# `canvas`, whose `node-pre-gyp install` post-install script tries to
+# fetch a pre-built linux-musl binary that doesn't exist (alpine =
+# musl, but node-canvas only publishes glibc binaries) and falls back
+# to compiling from source — which needs Python + gcc + Cairo headers
+# we deliberately don't ship in this image. The frontend build itself
+# never invokes canvas (no SSR happens at build time; the browser
+# provides the native canvas at runtime), so the package being
+# present-without-its-binary is harmless.
+RUN npm ci --no-audit --no-fund --ignore-scripts
 
 COPY frontend/ ./
 COPY shared/ /app/shared/