fix: make workspace plugins release correctly with separate-pull-requests

[slukes]

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease (if any source code was changed)
• Appropriate docs were updated (if necessary)

Fixes #2172 🦕

Problem

Since #2310, workspace plugins default to merge: false when separate-pull-requests: true is configured. On that code path, a candidate created for a dependency-only version bump ("cascade") is broken in two ways — both leftovers from when in-scope candidates were always merged into a single pull request:

1. No release labels. newCandidate() hardcodes labels: [] (and passes [] to strategy.buildReleasePullRequest). Under merge: true this was harmless because the Merge plugin unions labels from the real candidates, but as a standalone PR the cascade never carries autorelease: pending. Consequences:
   • findMergedReleasePullRequests filters merged PRs by these labels, so after the cascade PR is merged, no tag or GitHub release is ever created for it.
   • findOpenReleasePullRequests uses the same filter, so release-please does not recognize its own open cascade PRs and force-pushes their branches on every run.
2. Manifest entries attached to the wrong pull request. The manifest update covering all force-bumped paths is pushed onto newCandidates[0] only (introduced in fix: workspace plugins should update manifest versions #1429, when newCandidates[0] was by construction the single merged PR). With separate PRs it lands on whichever candidate sorts first alphabetically. Merging any other cascade PR leaves .release-please-manifest.json out of sync, and each subsequent run re-bumps from the package manifest and opens another doomed PR one patch higher. (If the first candidate's body happens to be unchanged, maybeUpdateExistingPullRequest skips the push entirely and the manifest update is silently dropped.)

Observed in production on a pnpm monorepo: dependency-only releases escalated three patch versions in a single day without a single tag or publish, while the manifest entries for those packages accumulated on an unrelated package's release PR.

Fix

• Pass the manifest's configured labels through buildPlugin to the workspace plugins (node-workspace, cargo-workspace, maven-workspace), and use them in newCandidate() — both the strategy.buildReleasePullRequest path and the fallback literal. Under merge: true this is a no-op (label union is unchanged).
• In WorkspacePlugin.run(), keep the existing single combined manifest update when merge is enabled; when it is disabled, attach each forced bump's manifest entry to its own candidate pull request. Candidates built from real releases already receive their manifest entry from the manifest PR builder, so nothing is duplicated.

Tests

Extended the plugin-compatibility test added in #2310 (test/plugins/compatibility/separate-pull-requests-workspace.ts) to also assert that each separate pull request carries the pending-release label and the manifest entry for its own path. Without the fix these assertions fail (expected [] to deeply equal [ 'autorelease: pending' ]); with it, the full suite passes (1201 tests).