Bug: release-please fails to parse tags correctly when component contains @ symbols, causing version leakage

#### Description

When using scoped package names (containing `@`) as the component value in conjunction with a tag-separator set to `@`, release-please fails to correctly isolate releases.

The parser appears to struggle with the multiple @ symbols in the generated tag (e.g., @wrc/package1@0.7.0), leading to "leaking" version bumps where a release for one package incorrectly triggers or groups with another foundation package. This results in unintended synchronized versioning across supposedly separate components.

#### Environment details

- OS: ubuntu-latest
- Node.js version: v22.15.1
- npm version: 11.0.0
- `release-please` version: ^16.0.0 (Latest stable)

#### Steps to reproduce

1. Configure a monorepo with multiple packages using scoped names (e.g., @project1/foundation and @project2/foundation).
2. In `release-please-config.json`, set `"tag-separator": "@"`.
3. Define components using the full scoped package name: "component": `"@project1/foundation"`
4. Commit a fix or feat to only one of the packages.
5. Run `release-please` and observe that the resulting PRs and tags incorrectly group or "leak" version updates to other foundation packages.

```ts
{
"group-pull-request-title-pattern": "chore(release): release ${branch}",
"label": ":ship: release: pending",
"release-label": ":ship: release: tagged",
"release-type": "node",
"tag-separator": "@",
"separate-pull-requests": true,
"packages": {
"@release-please-poc/@project1/foundation": {
"package-name": "@project1/foundation",
"component": "@project1/foundation"
},
"@release-please-poc/@project2/foundation": {
"package-name": "@project2/foundation",
"component": "project2/foundation"
}
},
"$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json"
}

```

### Expected behavior
release-please should treat` @project1/foundation` as a literal string for the component name, creating a unique tag and a separate PR regardless of the `@` characters.

### Workaround

Currently we have renamed the components to drop the `"@"` altogether and created bridge tags to use this new naming convetion. Doing this allows us to release single packages without bumping all other packages to the same version. Initial assumption here is that this is some sort of regex/parsing conflict within the libraries tag identification logic.

Thanks!