chore(deps): bump vulnerable transitive deps in npm/napi

[piscisaureus]

Resolves all 22 open Dependabot alerts. Every affected package is a
transitive devDependency, and each new version stays inside the
existing semver range, so only yarn.lock changes.

• tar 7.5.16 → 7.5.22 — unlimited decompression/parse DoS
  (GHSA-23hp-3jrh-7fpw, critical), infinite loop on negative entry
  size (GHSA-8x88-c5mf-7j5w, high), unbounded recursion in
  mapHas/filesFilter (GHSA-r292-9mhp-454m, high), plus two PAX record
  parsing crashes (GHSA-w8wr-v893-vjvp, GHSA-gvwx-54wh-qm9j, medium)
• js-yaml 3.14.2 → 3.15.2 and 4.2.0 → 4.3.2 — quadratic CPU
  consumption via merge keys and !!omap resolution
  (GHSA-2883-xcg3-v3hh, GHSA-5p4m-2wfm-xmqj, GHSA-52cp-r559-cp3m,
  high; GHSA-h67p-54hq-rp68, medium)
• brace-expansion 1.1.15 → 1.1.21 and 2.1.1 → 2.1.7 — expansion DoS
  via unbounded intermediate arrays, unbounded expansion length, and
  exponential-time consecutive {} groups (GHSA-rgw5-rvv9-x895,
  GHSA-mh99-v99m-4gvg, GHSA-3jxr-9vmj-r5cp, high)
• ip-address 10.2.0 → 10.7.2 — leading-zero octets decoded as
  decimal (GHSA-mwp4-54f8-5fhr, high), plus CIDR suffix and
  IPv4-mapped/NAT64 misclassification bypassing SSRF checks
  (GHSA-4xrf-jv44-h6hh, GHSA-22jq-vg5j-6vgg, medium)
• shell-quote 1.8.4 → 1.10.0 — quadratic-complexity DoS in parse()
  (GHSA-395f-4hp3-45gv, high)

They all land in the same lockfile, so they are bumped together rather
than one PR per advisory to avoid five PRs conflicting with each other.

[avocet-bot]

Review: #168 — chore(deps): bump vulnerable transitive deps in npm/napi

Reviewed head SHA: 6e59a720932113e9aa9c2127906072d4d2cc8cc1
Verdict: Approve — no blocking issues.

What this PR changes

denokv is Deno's key-value database. This PR touches only its Node/N-API bindings package (npm/napi), and within that package it modifies exactly one file: the Yarn (Berry / v2+) lockfile npm/napi/yarn.lock (+21 / −21 lines). A lockfile records the exact resolved version and integrity checksum of every dependency in the dependency tree; it is consumed by yarn install to produce a reproducible node_modules, but it is not itself published to npm and does not change any source, build output, or the package's declared dependency ranges in package.json.

The change bumps six transitive devDependencies to the patched versions flagged by Dependabot (22 open alerts across DoS, SSRF-check-bypass, and parser-crash advisories). Every bump stays inside the semver range already declared upstream, so no package.json range edits are needed and nothing but the lockfile changes:

Package (range)	Old → New	Kind
brace-expansion ^1.1.7	1.1.15 → 1.1.21	patch
brace-expansion ^2.0.2	2.1.1 → 2.1.7	patch
ip-address ^10.1.1	10.2.0 → 10.7.2	minor
js-yaml ^3.14.1	3.14.2 → 3.15.2	minor
js-yaml ^4.1.0	4.2.0 → 4.3.2	minor
shell-quote ^1.6.1	1.8.4 → 1.10.0	minor
tar ^7.4.3	7.5.16 → 7.5.22	minor

Because all seven advisory clusters land in the same lockfile, they are bumped together in one PR rather than as five conflicting per-advisory PRs — a reasonable choice, since separate PRs against one lockfile would serialize into rebase churn.

Verification performed

I reviewed the sole modified file and cross-checked each new version against the npm registry's published metadata, confirming for every entry that (a) the version exists, (b) it satisfies the semver range in its resolution key, and (c) the dependency block written into the lockfile matches what that exact version actually declares:

• Semver satisfaction — every new version falls inside the range in its resolution key. yarn install will not need any range or package.json edits.
• Dependency-block consistency — the one subtle point here is real and handled correctly: the brace-expansion@^2.0.2 entry drops concat-map from its dependency block, while the ^1.1.7 entry keeps it. This matches upstream: brace-expansion v2 genuinely has no concat-map dependency, whereas v1 still does. Every other entry's dependency block is unchanged and correct (e.g. tar keeps all five deps; both js-yaml entries keep their argparse/esprima deps and bin blocks).
• Lockfile integrity — all resolution keys are well-formed ("pkg@npm:version"), each entry carries a present, correctly-formatted (128-hex-char) checksum that changed in lockstep with its version, and the diff is a clean symmetric +21/−21 across exactly seven entries. No orphaned or dangling entries, no accidental removal of unrelated packages.
• Breaking-change risk — all bumps are within-range minor/patch upgrades; none forces a major. No API-surface concern for a lockfile-only change.
• Scope / blast radius — these are dev-only transitive build-tooling dependencies. The lockfile is not published, and none of these are runtime dependencies of the napi package, so there is no runtime or publish impact.

Findings

None blocking. This is a clean, minimal, within-range security bump and the lockfile is internally consistent with the real published package metadata.

One honest caveat, not a blocker: I did not independently recompute the Yarn Berry integrity checksums (that requires running yarn), so I am trusting that the author generated them via yarn install rather than hand-editing. They are all present, correctly formatted, and updated alongside their versions, which is consistent with a genuine yarn install run. If the project's CI runs yarn install --immutable (or equivalent), that job passing is the authoritative confirmation that the checksums are valid.

Review skill evidence

The primary review was produced by invoking the Claude Code pr-review-toolkit:code-reviewer subagent via the Task tool, which fetched the diff and cross-checked each bumped version and its dependency block against registry.npmjs.org. I confirmed the reviewed head SHA (6e59a720932113e9aa9c2127906072d4d2cc8cc1) matched headRefOid both before and immediately after the review, with no drift.