Removes the defensive guard added in pnpm#10575 that skipped deduplication
whenever the target workspace project's children weren't available in
the current resolution. In single-project operations the injected dep
is resolved against the same workspace package source, so dedupe is
safe and the link: protocol is preserved.

Adds a test case where the workspace dep target has its own children,
reproducing the bug the original PR was meant to fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Removes the defensive guard added in pnpm#10575 that skipped deduplication
whenever the target workspace project's children weren't available in
the current resolution. In single-project operations the injected dep
is resolved against the same workspace package source, so dedupe is
safe and the link: protocol is preserved.

Adds a test case where the workspace dep target has its own children,
reproducing the bug the original PR was meant to fix.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

## Issue

When `injectWorkspacePackages: true` is set and a workspace package depends on another workspace package that has its own dependencies, running `pnpm rm` from inside the dependent package's directory switches the lockfile protocol from `link:` to `file:`.

Reproduction (workspace where `a` depends on workspace `b`, and `b` has any dependency of its own):

```
cd packages/a
pnpm add redis
pnpm rm redis
# pnpm-lock.yaml: a's "b" entry switched from link:../b to file:packages/b
```

## Root Cause

The fix in #10575 added a defensive guard in `dedupeInjectedDeps` that skipped deduplication whenever the target workspace project's children weren't in `dependenciesByProjectId`:

```ts
if (!targetProjectDeps) {
  if (children.length > 0) continue
}
```

In single-project operations (`mutateModulesInSingleProject`, used by `pnpm rm` from inside a package directory) only the operated-on project is resolved. `dependenciesByProjectId` then only has that one project, so the guard fires for any workspace dependency whose target has children, and the protocol stays `file:`.

## Solution

In single-project mode the injected dep is resolved against the same workspace package source, so dedupe is safe — *except* for peer-suffixed depPaths, whose resolution depends on the importer's peer context (a plain `link:` would lose it). The new code dedupes whenever `targetProjectDeps` is missing for a known workspace project and the depPath has no peer suffix. The peer-suffix check compares the depPath against its peer-free `pkgIdWithPatchHash` (depPaths are built as `${pkgIdWithPatchHash}${peerDepGraphHash}`), so it's exact rather than a `(`-substring heuristic.

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Zoltan Kochan <z@kochan.io>