fix(deps): patch critical next RCE advisories (GHSA-p293/GHSA-2xp9), sharp and js-yaml

[AminDhouib]

Why

Advisories published after this fleet's last green dependency audit. This repo
was resolving next 16.3.0, sharp 0.35.3 and js-yaml 4.1.1, all in the production tree.

GHSA	severity	package	what it is
GHSA-p293-qw3h-jr36	critical (CVSS 9.0)	next	RCE on Windows-hosted servers
GHSA-2xp9-vwfh-vxw4	critical	next	RCE in the Image Optimization API via AVIF
GHSA-rgj7-g3m4-5g8c	high	sharp	<0.35.4, patched 0.35.4
GHSA-2883-w6h3-9f4x	high	js-yaml	patched 4.3.2 on the 4 line, 3.15.2 on the 3 line

Neither next advisory needs authentication.

What changed

apps/dokploy/package.json, the root package.json and pnpm-lock.yaml only. No workflow file is touched.

file	what	before	after
apps/dokploy/package.json	next	16.3.0	16.3.3
package.json	pnpm.overrides	3 existing keys	plus sharp@<0.35.4 to ^0.35.4 and js-yaml@4 to 4.3.2

• next 16.3.0 to 16.3.3 is a same-minor patch release, the smallest possible fix, and it stays on the 16 major.
• sharp still needed an override here even on the 16.3 line. The tree was resolving 0.35.3, one patch below the floor, and the next bump alone did not lift it. The override is version-scoped (sharp@<0.35.4) so it raises only copies below the floor.
• js-yaml is in the production tree, so it gets a version-scoped override (js-yaml@4) that keeps consumers inside their own major. A blanket override would drag any 3.x consumer onto 4.x, which removed safeLoad/safeDump.
• The three existing overrides are untouched. esbuild, better-call and @better-fetch/fetch keep their pinned values; the two new keys were added alongside them, not merged over them.
• Nothing unrelated moved. Verified semantically: the set of resolved name@version pairs was compared between HEAD and this branch. The total count is identical at 1826, the only differences are next and sharp's platform binaries, and exactly one declared specifier changed.
• @tiptap/* does not appear in this repo.

pnpm audit --prod production audit, before / after

Baseline captured on the unmodified tree at 295df490.

	critical	high	moderate	low	total
before	11	107	130	11	259
after	5	103	129	11	248

Watched packages flagged before: js-yaml, next, sharp.
Watched packages flagged after: none.

The criticals that remain belong to unrelated advisories outside the scope of this sweep and are deliberately untouched.

Verified locally

check	result
pnpm install --lockfile-only (pnpm 10.22.0 via corepack, the repo's own packageManager)	clean
resolved versions read back from pnpm-lock.yaml	next 16.3.3, sharp 0.35.4, js-yaml 4.3.2
resolved name@version pairs, before to after	1826 to 1826, only next and sharp binaries differ
declared specifiers changed	exactly 1 (next)
CR bytes in every changed file	0, counted byte-level
git ls-files --eol	i/lf w/lf

The build and typecheck were not run locally and are not claimed to pass. A full install of this monorepo is not reproducible on the machine this branch was prepared on. The repo has substantial CI (pull-request.yml, format.yml, dokploy.yml, upgrade-integration-test.yml among eight workflows), which is the gate. Please do not merge on a red build.

One thing deliberately left alone, and it is worth the owner's attention. packages/server/src/emails/ is a self-contained sub-project with its own pnpm-lock.yaml, outside the pnpm workspace, and that lockfile resolves next 14.1.4 transitively under react-email@^6.6.5. It declares no next of its own. Next 14 has no patched release at all for these advisories, so the only fix there is a major upgrade of react-email or of next, which is a migration rather than a dependency bump. It is untouched here and flagged rather than silently skipped. The same pattern, a preview/dev email server dragging in its own vulnerable next, was found in another repo earlier in this sweep.

Merge policy for this repo

This repository is not Dokploy source-bound. The classifier reads every column of both applications.csv and composes.csv and finds no unit binding a git source to it, so no push here can redeploy anything, and it is one of the names explicitly confirmed untracked by the classifier's own self-test. It does have CI, so this PR is being squash-merged once its checks are green, not before.