Faster, more reliable container builds on ARM64 infrastructure (QA)

This is an infrastructure-only fix that unblocks DSM's migration of QA (and eventually Production) hosting to ARM64 servers. It corrects build-tooling misconfigurations that were causing container builds to take 1h40m–2h or hang entirely, with the goal of cutting them to roughly 15 minutes. No application code changed.

DSM is moving its QA and Production build hosts from AMD64 to ARM64 chips. On the ARM hosts, container builds for the platform's apps were taking 1h40m–2h or stalling completely, making deployments unreliable. Root-cause analysis traced this to three build-configuration problems. The fix was cherry-picked straight to QA (rather than promoted through the normal dev→qa path) so it could ship without waiting on unrelated, not-yet-ready feature work (Admin Hub upload centers) that a prior promotion attempt had bundled in.

QA container builds should complete in minutes instead of hours and stop hanging, removing a blocker to the ARM64 server migration and making QA deployments dependable again. There is no user-facing functional change: this only affects how the apps are built and packaged. Once validated in QA, the same fix paves the way for the Production ARM migration.

Cherry-pick of the upstream ARM64 build fix (DSM_Frontend PR #988) to the qa branch. Verified in the diff:

• Dockerfile: base image switched from node:20-alpine (musl libc) to node:20-bookworm-slim (Debian glibc), avoiding known SWC segfault and musl-allocator slowdowns that silently force Next.js onto a 10–50x slower WASM compiler. System build deps migrated from Alpine apk to Debian apt-get equivalents (libcairo2-dev, libpango1.0-dev, libjpeg-dev, libgif-dev).
• package.json / apps/mail/package.json: moved the pnpm.overrides block (canvas → @napi-rs/canvas@0.1.69) from the mail app up to the workspace root, where pnpm actually honors it. Previously pnpm ignored it and installed legacy canvas@2.x, which has no ARM64 prebuilds and falls back to slow source compilation.
• pnpm-workspace.yaml: added overrides plus a supportedArchitectures block so the lockfile always records Linux ARM64 (glibc and musl) native binaries even when regenerated on a macOS dev machine.
• pnpm-lock.yaml: regenerated — legacy canvas/@mapbox/node-pre-gyp entries removed; prebuilt @napi-rs/canvas-* ARM64/x64 binaries added. Net +179 / −348 lines across 5 files; no application code touched.

Risk is moderate and confined to the build pipeline, not runtime features. The Debian base image is larger (~180MB → ~250MB) — an accepted trade-off. The main risk is image-rendering regression in the mail app, since the canvas library backing PDF/image rendering was swapped to @napi-rs/canvas. Mitigation: the cherry-pick merged the lockfile cleanly with no manual conflicts, the lockfile was re-validated against QA state, and canvas resolution was confirmed to point at @napi-rs/canvas@0.1.69. The change is isolated to QA first, so any issue surfaces before Production.

On the QA ARM build host/container: confirm uname -m is aarch64, node -p process.arch is arm64, and libc is GNU (not musl). Confirm @next/swc-linux-arm64-gnu and @napi-rs/canvas (not legacy canvas@2.x) are installed. Time a full ARM build — it should finish in well under 15 minutes (vs 1h40m–2h before) with no WASM fallback. Verify the AMD64 build still succeeds (no regression). Smoke-test the mail app on QA, specifically PDF/image rendering which now uses @napi-rs/canvas, and confirm all four apps (auth, mail, admin, vendor) start cleanly.