[P2.35] Decide the four remaining web-ui advisories, then raise the deploy audit gate above critical

[frankbria]

Split out of #1124 / PR for the next 16.3 security upgrade. Priority P2.35 — severity medium, category security.

Problem

Two coupled loose ends that #1124 deliberately did not resolve, because fixing either one alone makes things worse.

1. Four advisories remain after #1124, none covered by a Dependabot PR

With next at 16.3.0, npm audit in web-ui reports:

Package	Severity	Advisory
brace-expansion	high	GHSA-3jxr-9vmj-r5cp, GHSA-mh99-v99m-4gvg, GHSA-rgw5-rvv9-x895 (DoS)
js-yaml	high	GHSA-h67p-54hq-rp68, GHSA-52cp-r559-cp3m, GHSA-5p4m-2wfm-xmqj (DoS)
nanoid	high	GHSA-2v37-7h3g-55p8
@babel/core	low	GHSA-4x5r-pxfx-6jf8 (arbitrary file read)

All are dev/build-time dependencies, which is why they have been accumulating quietly. That is a reason to make a deliberate decision, not a reason to ignore them: build-time code still runs on CI runners with repo credentials in scope.

2. The deploy gate cannot see any of them

deploy.yml runs npm audit --audit-level=critical. Nothing below critical blocks a deploy, which is exactly how six high-severity findings accumulated unnoticed before #1124.

Why these have to move together

Raising the threshold to --audit-level=high today would immediately block every deploy on the three highs above. So the sequence is: decide on the four findings first, then raise the gate. Doing it in the other order breaks deploys; doing only the first half leaves the gate blind again the next time something lands.

Acceptance criteria

• An explicit accept-or-fix decision on each of the four, recorded somewhere durable (not just a PR comment)
• For any accepted: an allowlist entry with a reason and a review date, rather than a silent pass
• deploy.yml raised from --audit-level=critical to --audit-level=high once the above is clean
• Verify a deploy still succeeds with the raised threshold

Note

#1124 also surfaced that Dependabot closed a security PR (#1087) as "updatable in another way" and replaced it with #1123, which bumped only top-level postcss and did not touch the nested next/node_modules/postcss that carried the actual advisories. Worth keeping in mind here: an open Dependabot PR is not evidence that a class of advisory is being handled.

[frankbria]

Shipped in #1149. AC4 now verified on the box, which was the one item that could only be checked after merge.

The post-merge deploy of main (run 31459573866) with the raised threshold:

Deploy to Staging   npm audit --audit-level=high
Deploy to Staging   found 0 vulnerabilities
✓ Deploy to Staging in 1m0s

Live afterwards: /health 200, / 200, both PM2 processes online with 0 restarts.

Final state of all four ACs:

• Explicit decision on each of the four — all fixed, none accepted (each had fixAvailable: true with no effects, so npm audit fix resolved them inside the existing majors)
• No allowlist entry needed, because there is no residual risk to record. The decision itself lives in tests/test_deploy_audit_gate_1131.py, which also pins that the level never weakens below high
• Both deploy jobs at --audit-level=high
• Deploy succeeds with the raised threshold (above)

Two things worth recording for whoever hits them next:

1. npm audit fix produced a lockfile npm ci rejects. It reconciles against the installed tree, so npm 11.6.2 on my machine pruned two optional @emnapi platform entries that CI's npm (Node 20.19) expects. npm audit fix --package-lock-only edits the lockfile without consulting node_modules and keeps them. Caught by CI, not locally — npm test and npm run build both pass on a lockfile that npm ci will not install.
2. My first version of the regression table was green theatre. I set the version floors from the advisories' "patched in" versions, which the pre-fix lockfile already satisfied — so the whole class passed against the broken state. Floors now come from the shipped lockfile, verified by restoring main's and watching it fail 4/4.