feat(cli): ship only the dependency patches a code bundle applies [RED-893] [ship]

[sorccu]

Linear: RED-893

Affected Components

• CLI
• Test
• Docs

What and why

A code bundle ships a subset of the workspace but the workspace's entire
pnpm patchedDependencies map. A patch whose package belongs to an unbundled
member therefore applies to nothing, and pnpm 10/11 abort with
ERR_PNPM_UNUSED_PATCH as soon as they re-resolve.

The victim today is the lockfile pruner's own temp-dir install (RED-886): for
any patched workspace that bundles a subset of itself, pruning fails and the
unpruned lockfile ships with a warning — the outcome pruning exists to prevent.

Three commits, one per phase:

1. --config.allowUnusedPatches=true on the pnpm lockfile-only install, so
   the prune produces a lockfile instead of failing.
2. patched-dependencies.ts, a pure planner that decides which declarations
   no longer apply and produces the rewritten config/lockfile bytes.
3. Wiring into Bundler.finalize(), between pruning and embedded-package
   materialization, mirroring the existing filterTarballsByLockfile pattern.

How "unused" is decided

pnpm records each declaration's hash in the lockfile's patchedDependencies
section and repeats it as patch_hash=<hash> wherever the patch was applied.
The section mirrors the config, not the dependency graph, so pruning leaves an
unused declaration in place — the marker is what tells the two apart.

The test is differential: the marker must be present in the original
lockfile and absent from the pruned one. Absence alone would mean a lockfile
whose markers we cannot read classifies every declaration as unused and strips
them all, which is the one outcome that silently unpatches dependencies.

Notes for the Reviewer

The risk to weigh throughout is dropping a declaration that is genuinely in
force. Everything below is shaped by that.

• The removable-path allow-list is deliberately narrow. A declared patch
  path is user input that reaches a delete, and it can name any bundled file —
  an .npmrc carrying registry auth, a pnpmfile the lockfile records a checksum
  for, or a .patch fixture a check's own include glob pulled in. Only
  patches/<name>.patch is removable; a patch kept elsewhere loses its config
  and lockfile entry while the file stays (inert). The directory constant is
  shared with getAutoIncludes so the two cannot drift.
• Cases it deliberately declines, leaving the bundle exactly as pruning
  produced it: a declaration the project's own lockfile never recorded (the pnpm
  that wrote it may not read that declaration site — pnpm 11 ignores the
  package.json pnpm field, and pnpm-workspace.yaml is pnpm 10+); both
  declaration sites populated at once (pnpm honors one wholesale and which one
  depends on the major); any unreadable config or lockfile; any rewrite whose
  reparsed result is not the original minus exactly the removed keys.
• Atomicity is load-bearing. A half-applied filter ships a config/lockfile
  pair that fails the remote install (ERR_PNPM_LOCKFILE_CONFIG_MISMATCH, or
  ENOENT on a missing patch file). The apply step is pure map mutation over an
  already-computed plan — no IO, no parsing.
• Only the bundled copies are rewritten. The user's files are read and never
  written; a test asserts they are byte-identical after bundling.
• Cache hash: a rewritten root manifest ships as a synthesized file, so it
  is hashed the way on-disk manifests are, with version stripped. Hashing it
  verbatim would discard the runner's dependency cache on a release bump that
  changed no install input.
• Lockfile edits are a structural YAML edit, not a second install. Verified
  byte-identical to what pnpm itself writes for a config that never declared the
  patch, and a real-pnpm test asserts exactly that so a future pnpm formatting
  change fails the suite rather than shipping a subtly different lockfile.

Known residual, not addressed here: a rewritten pnpm-workspace.yaml is not
itself a cache-hash input, so the key tracks it only via the pruned lockfile
bytes. Closing that means adding a record type to a hash format with a
documented cross-language mirror, which wants coordinating separately.

pnpm 8/9 are EOL and out of scope. Bun and Yarn are unaffected: bun does not
raise this error, and Yarn Berry encodes patches as patch: locators inside the
lockfile, so pruning already removes them.

Verification

Behaviour verified empirically against pnpm 10.33.4, 10.34.5 and 11.23.0.
Coverage includes real-pnpm tests at three levels: the prune succeeding on a
patched partial-workspace bundle, the YAML edit reproducing pnpm's own bytes,
and an end-to-end case driving Bundler over a committed fixture and asserting
the produced tarball drops the unused patch file, its declaration and its
lockfile entry while keeping the still-applied one. Every fail-safe branch is
mutation-tested. Full unit suite: 2269 passing.

No new dependencies.

Not marked [ship] — release timing is yours to call.

[github-actions]

Auto-approved: ship/show PR from a same-repo branch.