BOM upload via projectName/parentName ignores parent scope, causing cross-namespace project collisions (regression impact after 4.14.2 → 5.0.2 upgrade)

### Current Behavior

We upload SBOMs via `POST /api/v1/bom` using `projectName` + `projectVersion` + `parentName` (not UUID-based `project`/`parent`), e.g.:

```bash
curl -X POST "$BOM_URL/api/v1/bom" -H "X-Api-Key: $BOM_UPLOAD_TOKEN" \
-F "autoCreate=true" \
-F "projectName=$CI_PROJECT_NAME-codebase" \
-F "projectVersion=$CI_COMMIT_BRANCH" \
-F "parentName=$CI_PROJECT_NAMESPACE" \
-F "isLatest=true" \
-F "bom=@cyclonedx-codebase.json"
```

This worked correctly on **4.14.2**. After upgrading to **5.0.2**, when a project with the same `projectName` + `projectVersion` already exists under a **different** parent namespace, the BOM is imported into that unrelated existing project instead of being created under (or matched against) the `parentName` we explicitly specified.

We have 200+ CI/CD pipelines already configured against this API contract (`projectName` + `projectVersion` + `parentName`), so switching every pipeline to UUID-based `project`/`parent` referencing is not a feasible short-term fix for us.

### Steps to Reproduce

1. Create Project A: `projectName=service-x`, `projectVersion=main`, `parentName=team-alpha` (via `autoCreate=true` on BOM upload).
2. Create Project B: `projectName=service-x`, `projectVersion=main`, `parentName=team-beta` (via `autoCreate=true` on BOM upload).
3. Re-upload a BOM for `projectName=service-x`, `projectVersion=main`, `parentName=team-beta`.
4. Observe: the BOM is imported into whichever project matched first by name+version, not necessarily the one under `team-beta`.

### Expected Behavior

`parentName` should be honored as part of the project lookup/match key. Two projects with identical `projectName` + `projectVersion` but different `parentName` should be treated as distinct projects, each scoped to their own parent — not merged/matched across namespaces. This matches the expected behavior already described in #5586.

### Environment

- Dependency-Track version: 5.0.2 (previously working correctly on 4.14.2)
- Database PostgreSQL 18
- Deployed in Kubernetes
- Upload method: `POST /api/v1/bom`, multipart form, `autoCreate=true`, `isLatest=true`
- Scale: ~200+ CI/CD pipelines relying on name/version/parentName-based resolution (not UUID-based)

### Impact

This causes SBOMs to be silently uploaded into the wrong project/namespace whenever a name+version collision exists across different parents in the portfolio — with no error or warning, making it hard to detect until someone notices vulnerability data appearing under the wrong team/parent. Given the scale of existing pipeline configurations, a UUID-based workaround is impractical for us in the near term, and we suspect other users relying on name-based resolution across large multi-team portfolios face the same risk.

### Suggested Fix

Include `parentName` (and `parentVersion`, if provided) as part of the project resolution key in the BOM upload endpoint, so lookups/auto-create are scoped within the specified parent rather than matching globally on `projectName` + `projectVersion` alone.

### Dependency-Track Version

5.x

### Browser

N/A

### Checklist

- [x] I have read and understand the [contributing guidelines](https://github.com/DependencyTrack/dependency-track/blob/main/CONTRIBUTING.md#filing-issues)
- [x] I have checked the [existing issues](https://github.com/DependencyTrack/dependency-track/issues) for whether this defect was already reported

Start at the POST /api/v1/bom endpoint and reproduce the collision using the projectName, projectVersion, and parentName combinations described in the issue. Trace project resolution and auto-creation for name-based uploads, then verify that matching and newly created projects remain scoped to the specified parent, including the re-upload case.

Written by the indexing model from the issue text.