fix(security): bump astro to 6.1.9 to close XSS in define:vars (SMI-4500) (#806)

* fix(security): bump astro to 6.1.9 to close XSS in define:vars (SMI-4500)

Closes Dependabot alerts #92 (packages/website/package.json) and #93
(package-lock.json) — both surface GHSA-j687-52p2-xcff (astro <6.1.6
XSS in define:vars via incomplete </script> tag sanitization).

Changes:
- packages/website/package.json: astro 6.1.3 → 6.1.9 (exact-pin per
  SMI-2162 audit:standards rule 12; ^6.1.6 was rejected as semver range)
- package.json devDependencies: add astro 6.1.9 to force hoisting at
  /app/node_modules/astro. Without this, npm 11 places astro only at
  packages/website/node_modules/astro, but @astrojs/[email protected] is
  hoisted at root and resolves astro via ESM from /app/node_modules/,
  causing "Cannot find package 'astro'" build error.
- package.json overrides: drop "astro": "^5.18.1". Was added in SMI-3688
  (PR #629) for the SSRF CVE in 5.x via @astrojs/vercel's pinned chain.
  No longer needed: @astrojs/[email protected] declares peer "astro: ^6.0.0",
  so it accepts the website's 6.1.9 directly. Override removal also
  resolves "EOVERRIDE: Override for [email protected] conflicts with direct
  dependency" error when both override and direct dep specify the same
  exact version.

Verification:
- npm install -> clean
- npm ls astro -> all chains at 6.1.9 (no <6.1.6, no 5.x)
- npm audit --omit=dev -> astro alert resolved (remaining uuid<14 chain
  via @azure/msal-node > unstorage > astro is PR-1/SMI-4501 territory,
  cleared once PR #805 merges and the uuid: ^14 override applies)
- npm run build -w packages/website -> Complete (0 errors, 0 hints,
  68 [WARN] about Astro.request.headers on prerendered pages — these are
  pre-existing tech debt; website was already on [email protected] before this
  change. Not introduced by this commit. Follow-up Linear issue should
  capture the 13 affected .astro pages.)
- npm test -w @skillsmith/website -> 171/171 pass
- npm run lint -> clean
- npm run typecheck -> clean
- npm run format:check -> clean
- npm run audit:standards -> 49 pass / 6 warns / 0 fail (89% compliance,
  baseline matches main)

Linear: https://linear.app/smith-horn-group/issue/SMI-4500
Project: GitHub Security Alerts (April 2026)

Closes Dependabot alerts #92, #93

Co-Authored-By: claude-flow <[email protected]>
Co-Authored-By: Claude <[email protected]>

* fix(deps): preserve multi-platform rollup native pins after astro 6.1.9 bump

Restores the lockfile state SMI-3984 (PR #490) carefully constructed to pin
@rollup/rollup-{darwin-arm64,darwin-x64,linux-arm64-gnu,linux-x64-gnu,linux-x64-musl}
across all CI platforms.

The original SMI-4500 commit (67b7a74) regenerated package-lock.json from
scratch via `rm -f package-lock.json && npm install` inside the
skillsmith-dev-1 container. That container runs linux/arm64 (Apple Silicon
Docker Desktop), so the regenerated lockfile only pinned the arm64 native
binding. CI runs on linux/x64 (ubuntu-latest) and could not load the rollup
native module — every Test (*) job and Website Build failed with
MODULE_NOT_FOUND on /app/node_modules/rollup/dist/native.js.

Fix: copy package-lock.json from origin/main (which still has all 5
platform pins from SMI-3984), then surgical-remove the stale
`packages/website/node_modules/[email protected]` block (left over from when the
override was `^5.18.1` and the website's astro had to nest), then re-run
`npm install` to refresh other entries. Lockfile now has both:

- All 5 rollup platform native packages pinned (verified via
  node -e "console.log(!!require('./package-lock.json').packages['node_modules/@rollup/rollup-linux-x64-gnu'])")
- [email protected] hoisted to root with no nested copy in packages/website/node_modules/

Verification:
- `npm ls astro` -> all chains show [email protected] deduped at root
- `npm run build -w packages/website` -> Complete (5.94s)
- `npm test -w @skillsmith/website` -> 171/171 pass
- `npm run lint` / `typecheck` / `format:check` -> clean
- `npm run audit:standards` -> 91% baseline

This unblocks PR #806 CI. Future lockfile regenerations should either:
1. Run inside a `--platform=linux/amd64` container (matches CI), or
2. Surgical-edit the lockfile rather than rm-and-regen, or
3. Use the `npm install` (not `--package-lock-only`) on origin/main's
   lockfile so existing platform pins are preserved.

Linear: https://linear.app/smith-horn-group/issue/SMI-4500

Co-Authored-By: claude-flow <[email protected]>
Co-Authored-By: Claude <[email protected]>

---------

Co-authored-by: Ryan Smith <[email protected]>
Co-authored-by: claude-flow <[email protected]>
Co-authored-by: Claude <[email protected]>

Author: 3 people