CI's dependency-audit job runs npm audit against a package-lock.json that bun install never regenerates or validates

[abayomicornelius]

Where: .github/workflows/ci.yml, dependency-audit job:

- name: Install dependencies
  run: bun install --frozen-lockfile
...
- name: Run npm audit (high and critical)
  run: npm audit --audit-level=high

(the same pattern repeats in release.yml's install step, and
security-audit.yml's dependency-audit job).

What's wrong: the repo ships two separate lockfiles —
bun.lock (the one every CI job actually installs from, via
bun install --frozen-lockfile) and a checked-in package-lock.json
(475KB, present in the repo root). npm audit resolves the dependency
tree it audits from package-lock.json, not from whatever bun install
just resolved into node_modules moments earlier in the same job — and no
CI workflow ever runs npm install, so package-lock.json is never
regenerated or validated against package.json/bun.lock by any
automated process. If a dependency is ever bumped via bun add/bun update (the tooling this repo actually uses, per its own engines/bun install everywhere) without a developer separately, manually running
npm install to refresh package-lock.json, the two lockfiles silently
diverge — and npm audit in CI keeps auditing a dependency graph that no
longer matches what's actually installed and shipped.

Impact: this is a false sense of security in the exact job that exists
to catch dependency vulnerabilities — npm audit --audit-level=high
passing doesn't guarantee the versions actually running in production are
vulnerability-free, only that a possibly-stale package-lock.json snapshot
is. It could also, conversely, report vulnerabilities in packages that
aren't even the versions actually installed.

Suggested fix: either regenerate package-lock.json from bun.lock
as a CI step before running npm audit (there isn't a fully equivalent
1:1 bun/npm lockfile converter, so this may mean switching the audit
tooling to something bun-native, e.g. bun audit if/when available, or
exporting a compatible lockfile), or commit to keeping both lockfiles in
sync as part of the dependency-update process and add a CI check that
fails if they've drifted.