Work Item adopts a 3-year-old MERGED PR into ReviewRemoteReference (legacy/next-gen WI branch-name collision)

## Summary

When a new next-gen DevOps Center **Work Item** is created and worked on, DevOps Center stamps `WorkItem.ReviewRemoteReference` with the number of an **unrelated, MERGED, ~3-year-old pull request** — without any code committed, branch pushed, or new PR opened in the current cycle.

The "random old PR" is deterministic: it is the legacy PR whose GitHub **head branch name equals the new Work Item name** (`WI-0000NN`). The next-gen DevOps Center restarted the Work Item auto-number sequence at `WI-000001`, so new branch names **collide** with branch names produced by the *legacy* (`sf_devops__*`) DevOps Center in 2023, whose merged PRs still exist in the repo. DevOps Center matches on head-branch name + pipeline entry base branch and does **not** filter out CLOSED/MERGED PRs.

## Steps to reproduce

1. A Git repo previously connected to **legacy** DevOps Center (branches `WI-0000NN`, merged PRs still present), now migrated to **next-gen** DevOps Center with the auto-number sequence restarted from `WI-000001`.
2. Create a new Work Item; it is auto-named `WI-0000NN`, reusing a branch name from the legacy era.
3. Move the Work Item to **In Progress** / start work (branch `WI-0000NN` gets associated).
4. Inspect: `SELECT Name, ReviewRemoteReference FROM WorkItem WHERE Name='WI-0000NN'`.

## Expected

`ReviewRemoteReference` is empty until a review/PR is actually created in the current cycle. Any adopted PR must be **OPEN** and target the **current** pipeline entry branch.

## Actual

`ReviewRemoteReference` is populated with a **MERGED, ~3-year-old** PR number from the legacy DevOps Center era (the PR whose head branch == the Work Item name), even though no code was committed and no new PR was opened.

## Evidence

Real current PRs in this repo are numbered ~12150–12200 (e.g. WI-000011 → PR #12175). The stamped values are off by ~12 000 and ~3 years:

| New Work Item (2026) | `ReviewRemoteReference` | Matched PR | PR head → base | PR state | Created |
|---|---|---|---|---|---|
| WI-000023 | `1` | #1 | `WI-000023` → `integration` | MERGED | 2023-05-30 |
| WI-000029 | `10` | #10 | `WI-000029` → `integration` | MERGED | 2023-05-31 |
| WI-000022 | `70` | #70 | `WI-000022` → `integration` | MERGED | 2023-06-05 |

For each affected branch there is **no open PR**; only legacy merged PRs (one per legacy stage). DevOps Center picks the one whose base is the pipeline entry branch:

```
gh pr list --head WI-000023 --state all
#1 MERGED base=integration
#3 MERGED base=uat
#5 MERGED base=stage
gh pr list --head WI-000023 --state open -> []
```

**Deterministic prediction:** the next Work Item will be WI-000030, whose legacy entry-branch PR is #19. A fresh WI-000030, once worked, will get `ReviewRemoteReference = 19` with no new PR created. (WI-000031→20, WI-000032→26, WI-000033→27, WI-000034→32, WI-000035→42.)

## Impact

Work Items appear already "in review" against a dead/merged PR; the UI/promotion logic links to the wrong PR and review state is corrupted. This affects **any** org migrated from legacy to next-gen DevOps Center against the same repo, since branch-name collisions are guaranteed once the sequence wraps past prior legacy numbers.

## Suggested fix

When resolving/adopting a PR for a Work Item branch, DevOps Center should: ignore CLOSED/MERGED PRs (adopt only OPEN ones), and/or restrict to PRs created at/after the Work Item, and/or match the exact branch ref it created this cycle rather than head-branch name alone.

## Environment

- Org Id: **00D1t000000xE35EAE** (production, DevOps Center host)
- API version: 65.0
- Pipeline entry branch (next-gen): `integ` (legacy was `integration`)
- Object/field: `WorkItem.ReviewRemoteReference` (string)