chore(deps): regenerate dependency transparency snapshots

[nedtwigg]

Runs node website/scripts/generate-deps.js and commits the result.

Why

The nightly security-audit workflow has one violated FAIL IF: the committed snapshots behind dormouse.sh/supply-chain are stale relative to the lockfiles already on main, so the page discloses dependency versions that don't match what ships. See #301 (the 2026-08-15 report).

The snapshots were last regenerated on 2026-07-22 (ed143a9). Everything since then is drift.

What changed

dependencies-npm.json

• @stricli/core 1.2.9 → 1.3.0
• react / react-dom 19.2.7 → 19.2.8
• new entry: @xterm/addon-webgl 0.20.0-beta.291 — added as a production dependency of lib and standalone by c221ca4 ("perf(lib): render terminals on WebGL"), so it genuinely belongs on the page

dependencies-cargo.json — direct: base64 0.22.1 → 0.23.0, getrandom 0.2.17 → 0.4.3, serde 1.0.228 → 1.0.229, serde_json 1.0.150 → 1.0.151.

The large net deletion (+22/−120) is the knock-on of those direct bumps, not a dropped disclosure: the superseded base64/getrandom versions demote from direct to transitive, syn 3.0.3 appears, and several build-time-only crates (prettyplease, leb128fmt, id-arena, duplicate foldhash/hashbrown, unicode-xid) fall out of the resolved graph.

dependencies-runtime.json regenerated byte-identical — the Node pin hasn't moved.

Verification

• pnpm install --frozen-lockfile → "Already up to date", so the npm scan reflects the locked tree
• the cargo side reads cargo metadata --locked
• ran the generator twice; second run produced no further diff

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying mouseterm with    Cloudflare Pages

Latest commit:	e60906c
Status:	✅  Deploy successful!
Preview URL:	https://c6776bd1.mouseterm.pages.dev
Branch Preview URL:	https://chore-regenerate-dep-snapsho.mouseterm.pages.dev

View logs

[dormouse-bot]

Checked the regeneration mechanically rather than by eye, since that's the part a human can't scan across 3.5k lines: the cargo file's 487 name@version entries are exactly the 487 sourced packages in standalone/src-tauri/Cargo.lock (no adds, no drops), the 13 direct entries are exactly the deps + build-deps + target-deps declared in standalone/src-tauri/Cargo.toml, and every npm version matches what pnpm-lock.yaml resolves for the four product importers. Both files are sorted per compareDependencyEntries / localeCompare, byte-identical to JSON.stringify(…, null, 2) + "\n", and contain no metadata-only edits — every +/- line is a version bump or a whole-entry add/remove. dependencies-runtime.json is correctly untouched (devEngines.runtime.version is still 24.18.0).

One thing worth raising beyond the diff. This snapshot drift isn't a one-off: the generate-deps.js FAIL IF in SECURITY.md has been red on every nightly audit since 2026-07-28 — 19 consecutive reports on #301 — because the snapshots are only ever regenerated by hand, while Renovate updates the lockfiles weekly. The audit catches it nightly, which is after dormouse.sh/supply-chain has already published versions that don't ship.

The standalone-smoketest job in .github/workflows/ci.yml already has everything the generator needs — pnpm install, dtolnay/rust-toolchain, and a cargo check that warms the same metadata — so appending a step there would move the detection onto the Renovate PR that causes the drift:

      - name: Dependency snapshots up to date
        run: |
          node website/scripts/generate-deps.js
          git diff --exit-code -- website/src/data/

That's a separate concern from this PR, so I haven't touched it here. Happy to open it as its own PR if you want it.