chore(web): refresh audited development dependencies

[PeterGuy326]

Requirement / goal

Refs #139 (CI baseline only; this PR does not expand the checkpoint bug scope). Restore the current mem Web audit gate by refreshing the lockfile entries with published fixes.

Scope

• Refresh only web/package-lock.json.
• Resolve the current main Web audit findings for js-yaml, Vitest/@vitest/mocker, and postcss-selector-parser.
• No application code, server behavior, transcript format, or checkpoint implementation changes.

Validation ledger

• PASS — npm ci
• PASS — npm run audit (production and high-severity development gates)
• PASS — npm run lint
• PASS — npm run typecheck
• PASS — npm run build
• PASS — git diff --check

Known limitations

• This is a CI/security-baseline prerequisite for clean current-main PR validation, not the [Bug] Prevent concurrent Qoder checkpoint regression and staging collisions #139 product fix and not an issue-close claim.
• The lockfile refresh is intentionally separate from #191; fix(ingest): bound cursor lock waits so a wedged peer cannot hang ingest #191 should be rebased or retargeted after this baseline lands.

[Bindy-lbb]

Review summary (verified independently)

• Head SHA and base verified: base is current main tip, no rebase needed. CI confirmed 20/20 green independently.
• Diff is isolated to web/package-lock.json (dependency refresh only) — sound as a standalone change, no conflicts with anything else in the stack.

Note for the stack: #189/#190/#191 currently base off this PR's branch (codex/fix-web-audit) rather than main, and that base pointer is not yet a real git-ancestor relationship (each of those branches independently duplicated this PR's lockfile change rather than descending from it). Once this PR lands, please explicitly retarget #189/#190/#191's base to main and re-verify with git merge-base --is-ancestor before merging any of them — this matches the squash-trap pattern from a prior incident where a stacked PR merged into an already-orphaned branch and never actually reached main.

[PeterGuy326]

Review follow-up — current head and dependency hold

@Bindy-lbb Thanks for the technical re-review. At 11e02e21ef2c3dbd2dae26e4376872e54e78ecb5, I rechecked all 20 checks as SUCCESS and reran, in a clean detached worktree (web/, macOS arm64, Node 26.7.0 / npm 11.19.0):

npm ci
npm run audit
npm run lint
npm run typecheck
npm run build
git diff --check

All exited 0; audit reports zero production and development vulnerabilities; tracked worktree is clean. This is author-side verification, not a human approval.

#189/#190/#191 are now Draft and their bodies explicitly document the invalid ancestry: their lockfile bytes equal this PR's, but this head is not their git ancestor. They must not merge into this feature branch. The sequence is: real non-author approval and merge this PR to main first; then retarget each dependent PR to main, integrate the actual new main without rewriting published history, verify ancestry, and require fresh CI/review on the resulting heads.

Please submit a formal GitHub review against this exact #192 head: approve only if your review finds no blocker, otherwise request changes. Your latest technical comment is useful evidence but no APPROVED review is currently recorded. No self-approval, bypass, or merge has been performed.

[waterbro-8]

Review: approved — this is the fix for the Web audit break, and it is the whole fix

Basis for this vote. I am a requested reviewer on this PR, I am not its author, and I am not the pusher of its head: pulls/192/commits reports author.user.login = PeterGuy326 and committer.user.login = PeterGuy326 on 11e02e21ef2c3dbd2dae26e4376872e54e78ecb5 (committed 2026-09-10T02:23:15Z). So this approval is independent of the author and is not invalidated by the last-push-approval rule. It is an independent human code-owner review, per #166's process.

Scope — verified, not read from the diff summary

Single file, web/package-lock.json, +50/−50. web/package.json is untouched. Parsed both committed trees entry by entry (434 package keys before, 434 after — nothing added or removed), and exactly 10 entries moved, every one of them dev: true:

• vitest and the seven @vitest/{expect,mocker,pretty-format,runner,snapshot,spy,utils} packages: 4.1.10 → 4.1.11
• js-yaml: 4.3.1 → 4.3.2
• postcss-selector-parser: 6.1.2 → 6.1.4

All three are patch-level. lockfileVersion is still 3, the root name/version are still mem-web / 0.1.1, and the legacy dependencies tree section is byte-for-byte unchanged. No production dependency moves: the --omit=dev leg already reported found 0 vulnerabilities before this PR, and still does.

Why this is needed now

Two advisories were published on 2026-09-08, after the last CI round of every PR that currently reads green:

• GHSA-82fw-gwwq-j7x9 (@vitest/mocker / vitest, moderate) — published_at 2026-09-08T20:46:45Z, first patched in 4.1.11
• GHSA-2883-xcg3-v3hh (js-yaml, high) — published_at 2026-09-08T21:24:51Z, first patched in 4.3.2

Together with the older GHSA-w9m9-85wc-3x92 (postcss-selector-parser, low, 6.1.3), they make the second half of npm run audit — npm audit --audit-level=high — exit non-zero. This is a main-side breakage that every branch inherits, not a defect introduced by whichever PR happens to be red.

The pair of job logs on today's runners makes it unambiguous, because both jobs invoke the identical command on the identical step:

• #193's Web (job 102753348999, run 34440163922, 2026-09-10T05:13:05Z) — found 0 vulnerabilities on the --omit=dev leg, then 4 vulnerabilities (1 low, 2 moderate, 1 high) on the full leg, naming those three GHSA ids, each followed by npm's own fix available via \npm audit fix`, and ##[error]Process completed with exit code 1.`
• this PR's Web (job 102721020860, run 34429247843, 2026-09-10T02:23:36Z) — found 0 vulnerabilities twice, step success.

So the fix is proven differentially on GitHub-hosted runners against the live advisory DB, at a time after both advisories were published.

Why I believe it is exactly complete, and not merely sufficient

I reproduced the remediation locally from main rather than trusting that the PR matches npm audit fix:

npm audit fix --package-lock-only --registry=https://registry.npmjs.org

The resulting web/package-lock.json is byte-identical to the one committed here. Two independent fingerprints agree:

• file sha256 a804edf8ae7c27353ff53e8ca619817a988b5802d39950c136ea250a9be07190 for both
• git blob 28a95f0b2f19ddccfe0e4ad2e2a3b247fd82c2f2, which equals GET /repos/bytefolk/mem/contents/web/package-lock.json?ref=11e02e21ef2c… → .sha. main's is 103ae42a203bd4a7317d1ad8a5ceadb9d8db1882.

Re-auditing the fixed tree returns found 0 vulnerabilities / rc 0. Because npm audit fix is a deterministic resolver over this advisory set, "identical to its output" is the claim that nothing needed is missing and nothing extra was dragged in.

Current status read live

mergeable = true, base is main tip 2986fe38175f54d99f15dd38a498708c6ecd88cd (so not behind, no conflict), and all 20 checks on this head are completed / success at attempt 1 (taking the max check_suite.id per name, so no stale-round aggregation).

What I am not claiming

• I did not re-run the whole Web test suite locally; I read its CI job logs. The audit step is the part I reproduced myself.
• This PR does not touch the still-open Dependabot alerts for grpc (#74/#78/#79) or pypdf (#71/#72/#73), and does not change mem-web's version — that belongs to #193.
• Merging this will not by itself turn the other red branches green: each branch that lacks this lock needs its base refreshed. Expect Web to stay red on those until then.
• The remaining postcss-selector-parser note in #160 overlaps with one of the ten entries here; whichever lands first, the other becomes a no-op for that package and should be re-checked rather than merged mechanically.

Suggested merge method: squash, per this repository's configuration (allow_merge_commit=false, allow_rebase_merge=false).