[Security] Example frontends carry an unmaintained second lockfile: Dependabot patches package-lock.json while bun.lock keeps the vulnerable version

[pathosDev]

What

The eight bundled example frontends each carry two lockfiles —
package-lock.json and bun.lock — but only the npm one is ever
installed by CI, and Dependabot's npm updater only ever rewrites the npm
one. The bun half therefore drifts silently, and a merged security bump
leaves the directory half-patched.

#1401 is the worked example. It bumped fast-uri 3.1.5 → 3.1.7 (two
waves of high-severity advisories: authority injection via an unvalidated
port, host confusion via IP-literal brackets, SSRF via IPv6 normalization
and repeated percent-decoding). After that merge:

directory	package-lock.json	bun.lock
examples/chat/frontend-angular	3.1.7 ✅	3.1.0 ❌
examples/voice/frontend-angular	3.1.7 ✅	3.1.2 ❌

Why nothing caught it

.github/workflows/examples.yml's frontend job installs with npm ci
(deliberately ci, not install, so a manifest/lockfile desync is an
error) and builds — from package-lock.json. Nothing anywhere installs
the example bun.lock files, so no gate can see them diverge. The
workflow header already documents the sibling failure mode that actually
happened (ts-pattern declared in six package.json files and missing
from all six package-lock.json files, unnoticed because nothing
installed them); this is the same class of defect, one lockfile over.

A second desync found while fixing it

Re-resolving the two bun lockfiles surfaced a pre-existing violation
unrelated to fast-uri: both package.json files declare

"overrides": {
  "@hono/node-server": "^2.1.0",
  "@modelcontextprotocol/sdk": "^1.30.0"
}

while the committed bun.lock pinned @hono/node-server@1.19.14 and
@modelcontextprotocol/sdk@1.29.0 — i.e. the lockfile contradicted the
declared override. package-lock.json had already resolved them
correctly (2.1.0 / 1.30.0), which is further evidence that the bun half
is the unmaintained one.

Fix

Immediate: sync both bun.lock files (bun update fast-uri --lockfile-only in each directory), which also records the overrides and
converges the two lockfiles.

Structural (the part worth discussing): the drift can recur on the next
Dependabot bump. Options, roughly in increasing cost —

1. Add a bun install --frozen-lockfile leg to the frontend matrix, so
   a desynced example bun.lock is a red check rather than an invisible
   one. Cheapest, and it mirrors what the npm leg already does.
2. Drop the example bun.lock files entirely and let the frontends be
   npm-only, since that is what CI and the documented build path use.
3. Keep both and add a periodic sync job.

(1) or (2) both close the gap; (3) does not, it only shortens the window.

Refs #1401. Related: #779 (the same package is vulnerable in the root
bun.lock through fastify > fast-json-stringify > ajv, inside the
runtime closure — a separate and worse exposure that Dependabot is blind
to by design).

[pathosDev]

Option 1 is implemented, and measuring it corrected the issue body

I wrote option 1 above as if a bun install --frozen-lockfile leg would
close this gap. It does not, and the difference is worth recording
before anyone treats the box as ticked.

Measured with bun install --frozen-lockfile --dry-run against two
reconstructed states of examples/chat/frontend-angular:

state	result
pre-fix: fast-uri 3.1.0 and the override violation	exit 1 — note: overrides in package.json changed since bun.lock was saved
fast-uri 3.1.0 alone, overrides already corrected	exit 0

So the check validates manifest ↔ lockfile consistency, and fast-uri
appears in no package.json at all — 3.1.0 satisfies the ^3.0.1 that
ajv asks for, so a stale-but-in-range transitive dependency is
invisible to it.

The leg would therefore not, on its own, have caught #1401. On the
tree as it actually stood it would have gone red — but through the
unrelated override violation described above, not through fast-uri.
Once that violation is fixed, the next npm-only security bump passes it
silently.

What landed anyway, and why

The leg is still worth having: it closes a real class that had no
coverage at all (a bun.lock contradicting its own manifest), it is
cheap, and it mirrors what the npm leg already does. It runs before the
Node setup so a desync is reported without paying for an install and a
build, and it was verified green against all eight matrix directories
first, so it does not arrive red. The measured limitation is written
into the step's comment rather than left to be rediscovered.

What is still open

Closing the class #1401 actually belongs to needs a cross-lockfile
version-map comparison — parse package-lock.json and bun.lock in
the same directory and fail where the resolved version of a shared
package disagrees. One caveat found while looking at it: the two
resolvers legitimately land on different patches (npm has
@hono/node-server@2.1.0, bun 2.1.1, both satisfying ^2.1.0), so a
strict equality check would be noisy as written and needs a deliberate
rule about what counts as disagreement.

Option 2 — dropping the example bun.lock files entirely, since npm ci
is what CI and the documented build path use — remains the cheaper way to
make the whole question go away, and is not foreclosed by this change.

Keeping this open for that decision.