fix(deps): move next 16.3.6 to 16.3.8, clearing six OSV advisories on main's lockfile

[objectstack-fleet]

Fixes #22148

Clause-②: no

What this does

Moves every next resolution in the lockfile from 16.3.6 to 16.3.8. That patch release is the fixed version of all six OSV advisories that main's scheduled Validate Package Dependencies scan is red on.

• apps/docs/package.json: the exact pin "next": "16.3.6" becomes "next": "16.3.8". It is the only next declarer in the workspace.
• pnpm-lock.yaml: regenerated by pnpm install, not edited by hand. better-auth@1.7.3 takes next as an optional peer, and pnpm resolved it to the same version as the docs pin. Its resolution follows to 16.3.8 with no change to packages/plugins/plugin-auth/package.json.
• No overrides: entry, no exemption, no edit to validate-deps.yml, osv-scanner.toml or scripts/osv-base-relative.mjs.
• @objectstack/docs is private, and no published package's manifest or files[] content changes, so this PR is labelled skip-changeset.

The fixed versions, read before choosing

Read from the OSV export bucket (storage.googleapis.com/osv-vulnerabilities/npm/ID.json). All six records were published 2026-10-07 and modified 2026-10-07T20:45Z.

Advisory	Affected range on the 16.x line	Fixed in
GHSA-mcj8-r9mp-w47p	16.0.0 up to 16.3.8 (also 15.0.0 up to 15.5.27)	16.3.8
GHSA-f87g-xv8r-7p7x	16.0.0 up to 16.3.8	16.3.8
GHSA-cjq9-62q9-8jv4	16.0.0 up to 16.3.8	16.3.8
GHSA-4jqv-mc3x-m676	16.0.0 up to 16.3.8 (also 15.0.0 up to 15.5.27)	16.3.8
GHSA-3w37-wq28-93x7	16.3.0 up to 16.3.8	16.3.8
GHSA-39w2-rjm5-chcv	16.0.0 up to 16.3.8	16.3.8

Every one of the six has a fixed release, so no exemption is needed.

Why 16.3.8 and not 16.4.0 (latest): 16.3.8 is the smallest move that fixes all six. It is a patch inside the line already pinned, published 2026-09-30. Every next peer range in the tree accepts it: fumadocs-core@16.14.4 and fumadocs-ui@16.14.4 (16.x.x), fumadocs-mdx@15.2.3 (^15.3.0 || ^16.0.0), better-auth@1.7.3 (^14.0.0 || ^15.0.0 || ^16.0.0).

Evidence (head b6e4c2caca, merge base 959c209d56)

Lockfile.

• grep -c 'next@16.3.6' pnpm-lock.yaml returns 0 at the head (it was 22 at the base).
• Every remaining next@ resolution in the lockfile names 16.3.8 (26 occurrences). No next@ resolution of any other version remains.
• The lockfile diff is a pure version swap. The 64 removed and 64 added lines are identical once 16.3.6 and 16.3.8 are normalised, apart from 10 integrity hashes: next, @next/env and the eight @next/swc-* binaries.
• pnpm install --frozen-lockfile exits 0 ("Already up to date").

OSV, scanned locally with the same scanner version the workflow pins: osv-scanner v2.5.0, the release binary, whose sha256 matches the release's SHA256SUMS. It used an offline npm database freshly downloaded from the OSV bucket at 2026-10-08T04:13Z. Both scans load each side's own osv-scanner.toml, as the workflow does.

• Merge base 959c209d56: exit 1, six findings, all on next@16.3.6. Those are the six above, and they serve as the positive control.
• Head b6e4c2caca: exit 0, zero findings. The ledger's one exemption (GHSA-hp3w-g68c-fv3c, sprintf-js) is still applied on both sides.
• I also fed both result files to scripts/osv-base-relative.mjs. It printed: OSV base-relative verdict against the merge base (959c209d56a8): 0 introduced, 0 inherited, 6 resolved.
• The scanner's offline mode has a trap. Run without --download-offline-databases, it loaded no database and returned zero findings with exit 0, even for the base lockfile. So each leg above was checked for its Loaded npm local db line, and the base leg's six findings show the database was really loaded.
• This PR's own validate-deps.yml run is 37727268306, job 113148187921, at head b6e4c2caca: OSV base-relative verdict against the merge base (959c209d56a8): 0 introduced, 0 inherited, 6 resolved. (Seat amendment: the run existed only after the PR was opened.)

The docs site builds with the new next. I ran the production build command read from apps/docs/vercel.json (pnpm turbo run build --filter=@objectstack/docs) with TURBO_FORCE=true, as the Build Docs job does.

• Output: ▲ Next.js 16.3.8 (Turbopack) · ✓ Compiled successfully in 90s · ✓ Generating static pages using 2 workers (1243/1243).
• Turbo reported 2 of 2 tasks successful and 0 cached. apps/docs/.next/BUILD_ID is present.
• pnpm --filter @objectstack/docs run typecheck (fumadocs-mdx && next typegen && tsc --noEmit) exits 0.

Gates. I derived them from this worktree with node scripts/pm/dispatch-gates.mjs --commands --repo objectstack-ai/objectstack at b6e4c2caca, which gave the same 41 commands as at dispatch, and ran all 41.

• Reconciled with --ran: 41 derived famil(ies) accounted for — 39 run, 2 NOT-MEASURED (2 DERIVED from a recorded exit 3).
• 39 exit 0, including check-osv-exemptions and its self-test, osv-base-relative --self-test, check:override-consistency, check:vendor-export-contract-resolve, check:nul-bytes and check:published-files.
• NOT MEASURED: pnpm check:dual-build-cjs-loads and pnpm check:lean-entry-closure both exit 3, PREREQUISITE NOT MET. They load built entry points of the whole workspace, and only the docs build closure (@objectstack/spec) was built here. CI's full build measures them. This diff changes no package's source, build config or exports.
• check:dts-closure and check:sourcemap-no-sources-content swept the one built package (@objectstack/spec).
• Lint: eslint's own JSON output marks both changed files "File ignored because no matching configuration was supplied". That is 2 files and 0 linted, because eslint's files globs are JS/TS only. Type-aware linting is not enabled (no parserOptions.project), so this diff cannot move any untouched file's verdict.

Acceptance notes

• During the docs build's static generation, the OG image route logged one non-fatal "Failed to load dynamic font" (a self-signed certificate on the container's egress proxy). The build completed, and this is an environment reading, not a change in behaviour.

---

Generated by Claude Code