chore(deps): resolve dependency vulnerabilities (2026-10-06)

`npx better-npm-audit audit` (audit-all) and `--production` (audit-prod)
were red with 42 new advisories (51 npm audit entries) across 16 root
packages. Each package was assessed separately against the decision
ladder earlier audit fixes used (94b07cc, 2481e2b, eab374b,
f16fb4b): lockfile-only where nothing pins the package, delete an
override that has become a stale ceiling, bump or add an override only
where a consumer floors a vulnerable range, and an .nsprc exception only
where no patched release exists.

Lockfile-only (no override key, every consumer range admits the fix):
- axios 1.18.1 -> 1.20.0 (12 advisories; via posthog-node ^1.8.2)
- fast-uri 3.1.7 -> 3.1.8 (GHSA-hrr3-gc8f-f4qj; ajv ^3.0.1)
- http-cache-semantics 4.2.0 -> 4.3.0 (GHSA-ch52-4w7c-c8xp). The advisory
  is disputed upstream (issue #56 closed not_planned, withdrawal requested
  in github/advisory-database#10139) and 4.3.0 leaves the max-stale path
  unchanged; it only falls outside the `<=4.2.0` range. Unreachable here:
  make-fetch-happen builds its CachePolicy with `shared: false`. 4.3.0 does
  carry the merged Vary fix.
- markdown-it 14.2.0 -> 14.3.2 (GHSA-253c-mchw-3w2r; vsce ^14.1.0). 14.3.2
  rather than 14.3.1 because it backports a further smartquotes DoS fix.
- probe-image-size 7.3.0 -> 7.4.0 (GHSA-gjj5-9665-rwrc; less ^7.2.3)
- proxy-addr 2.0.7 -> 2.0.8 (GHSA-jqcg-44mw-7w3h, critical; express
  ^2.0.7). Not reachable: both express apps keep `trust proxy` false, so
  proxy-addr compiles to trustNone and the patched trustSingle/trustMulti
  matchers never run.
- source-map-js 1.2.1 -> 1.2.2 (GHSA-68fv-2mgg-jv7q; postcss ^1.2.1)

Deleted overrides that had become stale ceilings (94b07cc: "the
lockfile is the floor; the drift check enforces it"). Every consumer
range admits the patched release, so only our own key held the tree down:
- brace-expansion: all three ranged keys. 1.1.18/2.1.4/5.0.9 ->
  1.1.21/2.1.7/5.0.12 across all 11 copies (GHSA-q2hr-2g5m-vwhr,
  GHSA-qhr7-859c-m2p7, GHSA-6j4f-fj2g-mc7p).
- dompurify 3.4.15 -> 3.4.16 (GHSA-p98j-92pf-mc4p, GHSA-6688-9rhm-gjv2;
  mermaid ^3.3.3).
- morgan 1.12.0 -> 1.12.1 (GHSA-9f6g-j8ch-79g4; koa-morgan ^1.6.1).
- smol-toml 1.8.0 -> 1.9.0 (GHSA-r4xh-jqrq-34v2; cspell-config-lib ^1.6.1).
- undici: both ranged keys. 6.28.0/7.29.0 -> 6.29.0/7.30.0 (10
  advisories; @actions/* ^6.23.0, cheerio ^7.19.0).

Deleting a key alone leaves the lockfile untouched, because the locked
version still satisfies the consumer range, so each package was
re-resolved with `npm update`. npm 10.9.4 kept the root brace-expansion
1.1.18 and @vscode/test-cli's 5.0.9 even then, so those two lockfile
entries were dropped and re-resolved.

Bumped override:
- ip-address 10.4.0 -> 10.7.3 (GHSA-rpw4-54j3-4h4q, GHSA-2vr4-cq9g-pvrc,
  GHSA-j6r3-76f7-8jcv, GHSA-h3mg-xc3c-68pw; 10.7.1 is the minimum fix).
  Kept rather than deleted: build.ts propagates this key into
  dist/sql-lsp-modules, an isolated install with no lockfile, where
  removing the pin leaves a reused tree on 10.4.0. 10.7.3 is the latest
  patch and what an unpinned resolve picks. Correction to eab374b: that
  copy is reached only via sqlite3 -> node-gyp -> make-fetch-happen ->
  socks, not by the SQL LSP's host resolution.

New override:
- katex "0.18.2" (GHSA-238p-pmpm-9mq7, low). mermaid declares
  ^0.16.45 and every mermaid up to 12.1.0 declares ^0.16.x, a line with no
  backport, so the consumer itself floors a vulnerable range. 0.16 -> 0.18
  only renames internal CSS classes and the private __defineFunction
  API; mermaid makes a single renderToString call and its CSS targets only
  `.katex`. katex ships in no bundle.

.nsprc accepted risk (no patched release on any line), expiry 2026-11-06:
- braces GHSA-vfj7-8cjw-p6xm (high): <=3.0.3, and 3.0.3 is latest.
- sprintf-js GHSA-hp3w-g68c-fv3c (moderate): <=1.1.3, and 1.1.3 is latest.
Both are in the production tree only because @deepnote/sql-language-server
lists jest under `dependencies`. Neither reaches any esbuild metafile,
dist/sqlLanguageServer.cjs or dist/sql-lsp-modules.

Verified: `better-npm-audit audit` and `--production` both exit 0 with
only the elliptic, braces and sprintf-js exceptions applied; exactly the
25 intended lockfile entries move and none are added or removed; a second
`npm install` leaves package-lock.json byte-identical; a clean build
writes ip-address 10.7.3 into dist/sql-lsp-modules, whose own audit
reports 0 vulnerabilities; typecheck, lint and 2826 unit tests pass.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01USEnGCRP32gQH4AZHbRVqQ

Author: tkislan

.nsprc

@@ -2,5 +2,13 @@
     "GHSA-848j-6mx2-7j84": {
         "notes": "CVE-2025-14505: elliptic's ECDSA signing mis-computes the byte length of the nonce k when k has leading zeros, emitting a truncated signature; an attacker who obtains both a faulty and a correct signature over the same input can recover the private key. Accepted risk: dev-only transitive dependency, absent from the production tree (`npm ls elliptic --omit=dev` is empty). Reached only via node-stdlib-browser@1.3.1 -> crypto-browserify@3.12.1 -> browserify-sign@4.2.5 / create-ecdh@4.0.4 -> elliptic@6.6.1. node-stdlib-browser is a devDependency used exclusively by build/esbuild/build.ts, whose stdlib polyfill plugin is applied only to the web test entry (src/test/web/index.ts -> out/extension.web.bundle.js, excluded from the VSIX by `out/**` in .vscodeignore); the production desktop and web bundles never pull it in, confirmed by the absence of node_modules/elliptic, node_modules/browserify-sign and node_modules/crypto-browserify inputs in dist/*.esbuild.meta.json. No code in this extension performs ECDSA signing. No patched upstream release is currently available: every published elliptic release is affected (range <=6.6.1, and 6.6.1 is the latest version on npm, published 2024-11-13), GitHub lists no patched version, and npm audit reports fixAvailable:false. The real remediation is an upstream elliptic release, or dropping node-stdlib-browser from the web test bundle in favour of native browser crypto.",
         "expiry": "2026-10-17"
+    },
+    "GHSA-vfj7-8cjw-p6xm": {
+        "notes": "CVE-2026-93687: braces has no recursion-depth guard in its parse/compile/expand walkers, so a deeply nested brace pattern exhausts the call stack and throws an uncaught RangeError (denial of service). Accepted risk: not shipped and not reachable with untrusted input. One copy, braces@3.0.3 (held by the root `braces` override), pulled in by micromatch@4.0.8 and chokidar@3.5.3. npm counts it as production only because @deepnote/sql-language-server@3.0.0 lists jest@^26.0.1 under `dependencies` (jest -> @jest/core -> micromatch) and @jupyterlab/filebrowser lists jest-environment-jsdom; neither runs at runtime. No dist/**/*.esbuild.meta.json has node_modules/braces or node_modules/micromatch inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX by .vscodeignore. The dev-time callers (mocha and gulp via chokidar; esbuild-plugin-import-glob and @vscode/vsce via fast-glob) expand only glob patterns written in this repository. No patched upstream release is currently available: every published braces release is affected (range <=3.0.3, and 3.0.3 is the latest version on npm, published 2024-05-21), GitHub lists no patched version, npm audit reports fixAvailable:false, and micromatch@4.0.8 and fast-glob@3.3.3 (both latest) require braces ^3.0.3. When a patched braces is published, raise or delete the exact `braces` override (it would otherwise hold the tree on 3.0.3) and remove this entry.",
+        "expiry": "2026-11-06"
+    },
+    "GHSA-hp3w-g68c-fv3c": {
+        "notes": "CVE-2026-97058: sprintf-js passes unbounded precision specifiers (e.g. `%.999f`) straight to Number#toFixed/toExponential/toPrecision, which throw an uncaught RangeError, so an attacker who controls a format string can abort the calling operation. Accepted risk: not shipped and not reachable. One copy, sprintf-js@1.0.3, reached only via @istanbuljs/load-nyc-config@1.1.0 -> js-yaml@3.15.2 (held by the `js-yaml@3` override) -> argparse@1.0.10 -> sprintf-js. It is in the production tree only because @deepnote/sql-language-server@3.0.0 lists jest under `dependencies` (jest@26.6.3 -> @jest/core -> @jest/transform -> babel-plugin-istanbul@6.1.1 -> @istanbuljs/load-nyc-config); the dev path is nyc@15.1.0. load-nyc-config calls only js-yaml load(); js-yaml 3 requires argparse solely from its bin/js-yaml.js CLI, which nothing here invokes; and argparse formats only its own usage/help templates with sprintf. No dist/**/*.esbuild.meta.json has node_modules/sprintf-js or node_modules/argparse inputs, dist/sqlLanguageServer.cjs bundles neither, dist/sql-lsp-modules does not install them, and node_modules/** is excluded from the VSIX. No patched upstream release is currently available: every published sprintf-js release is affected (range <=1.1.3, and 1.1.3 is the latest version on npm, published 2023-09-11), GitHub lists no patched version, and npm audit reports fixAvailable:false. argparse@1 pins sprintf-js ~1.0.2, so a future 1.1.x fix would still need an override; the alternative remediation is overriding `argparse@1` to 2.0.1, whose CommonJS API js-yaml 3 load() never touches.",
+        "expiry": "2026-11-06"
     }
 }