RN harness projects depend on react-native-windows@1.0.0, a placeholder package with no code — `npm run windows` cannot build

## Summary

All three React Native harness projects depend on **`react-native-windows@1.0.0`, which is a placeholder package that contains only a `package.json` and no code**. As a result `npm run windows` cannot build any of them.

| Project | current | should be |
|---|---|---|
| `tests/stress_perf_rn/StocksGrid` | `^1.0.0` | `^0.82.5` |
| `tests/stress_perf_rn/VirtualList` | `^1.0.0` | `^0.82.5` |
| `tests/startup_perf/BlankRNW` | `1.0.0` | `0.82.5` |

## How it happened

react-native-windows ships on the `0.x` line — npm's own `latest` tag is `0.84.0` and `v0.82-stable` is `0.82.8`. A stray `1.0.0` exists on the registry and sorts above every `0.x`, so Dependabot treated it as a major upgrade:

- #127 (`c489c475`) — StocksGrid: *"Updates `react-native-windows` from 0.82.5 to 1.0.0"*
- #123 (`25e1bb6c`) — VirtualList: same
- #156 (`d55f9e91`) — BlankRNW: *"bump @xmldom/xmldom and react-native-windows"*

Each was driven by a transitive security alert (`fast-xml-parser`, `@xmldom/xmldom`). Jumping to the stub "resolved" the alert by deleting the dependency subtree entirely — #127 alone removed 1,869 lines from the lockfile.

The published stub is clearly not the real package:

```json
{
"name": "react-native-windows",
"version": "1.0.0",
"description": "React Native platform extensions for the Universal Windows Platform.",
"main": "index.js",
"author": "",
"license": "ISC"
}
```

`main` points at an `index.js` that isn't in the tarball.

## Measured impact

With the stub installed:

- `@react-native-community/cli config` reports platforms `['ios', 'android']` — no `windows`, so `npm run windows` / `run-windows` cannot work
- `react-native bundle --platform windows` fails with `Invalid platform "windows" selected`
- `node_modules/react-native-windows/PropertySheets/External/Microsoft.ReactNative.Composition.CppApp.props` — imported by the checked-in `StocksGrid.vcxproj` — does not exist. The project has an explicit `` for exactly this: *"This project references targets in your node_modules\react-native-windows folder. The missing file is {0}."*
- `scripts/rnw-dependencies.ps1` and `@react-native-windows/cli/lib-commonjs/utils/vsInstalls.js`, both referenced by `tests/stress_perf_rn/README.md`, do not exist

Installing the real `react-native-windows@0.82.5` flips every one of those:

| check | stub `1.0.0` | real `0.82.5` |
|---|---|---|
| CLI platforms | `ios, android` | `ios, android, **windows**` |
| `Microsoft.ReactNative.Composition.CppApp.props` | missing | present |
| `...CppApp.targets` | missing | present |
| `scripts/rnw-dependencies.ps1` | missing | present |
| `@react-native-windows/cli` | missing | present |
| `react-native bundle --platform windows` | `Invalid platform` | succeeds (1,021,436 bytes) |

`0.82.5` is also what the repo already documents and pins elsewhere:

- `tests/stress_perf_rn/README.md`: *"Versions: RN 0.82, react-native-windows 0.82.5"*
- `StocksGrid.vcxproj` line 2: ``
- `StocksGrid/packages.lock.json`: `Microsoft.ReactNative` resolved `0.82.5`

## Why I didn't just send the fix

Restoring `0.82.5` re-introduces `@xmldom/xmldom@0.7.13` (deprecated, *"this version has critical issues"*) via `@react-native-windows/cli@0.82.0`, plus a nested `fast-xml-parser@4.5.7`. That is exactly what #127, #156 and #1169 ("Clear all 17 Component Governance alerts in the RN harness lockfiles") were removing.

So the real decision is **a buildable perf harness vs. those Component Governance alerts**, which is a policy call for maintainers, not something to slip into a drive-by PR. Options as I see them:

1. **Pin `0.82.5` and accept the alerts** — restores the documented, native-project-matching setup. Simplest; reopens the CG alerts.
2. **Pin `0.82.5` plus npm `overrides`** to force patched `@xmldom/xmldom` / `fast-xml-parser`. Keeps alerts closed, but `@xmldom/xmldom` 0.7 → 0.9 is a major bump inside the RNW CLI and needs a real `run-windows` to validate.
3. **Move to a newer RNW line** (`0.82.8`, or 0.83/0.84). Likely carries newer transitive deps, but the checked-in `windows/` projects pin `Microsoft.ReactNative 0.82.5`, so the NuGet side would need regenerating too.

Whichever route, the fix should also stop Dependabot from redoing it. The repo already uses the scoped-ignore pattern for MessagePack in `.github/dependabot.yml`; note that an `ignore` naming only a dependency suppresses **security** updates as well, while scoping it to `update-types: ["version-update:semver-major"]` leaves the security path open — and it was the security path that produced these three bumps.

## Also worth noting

No workflow in `.github/workflows` has a `setup-node` or `npm` step — there is no CI coverage for any Node project in the repo, which is why this and the HeadTrax crash (#1175) both went unnoticed. A small job running `npm ci && npm run lint && npm run typecheck` per Node project would catch this class of regression.

Lint/type fixes for these same three projects are in #1176, which deliberately leaves this dependency issue alone.

*Environment note: verification ran on Node 22 against a registry mirror. Every upstream version claim here was cross-checked against jsDelivr/unpkg, because the mirror's package index lagged npm in at least two cases.*

Inspect the package manifests and lockfiles under tests/stress_perf_rn/StocksGrid, tests/stress_perf_rn/VirtualList, and tests/startup_perf/BlankRNW, then read tests/stress_perf_rn/README.md and .github/dependabot.yml. Confirm the chosen React Native Windows dependency policy with maintainers, update the affected projects accordingly, and verify that npm run windows works without undoing the intended dependency-alert handling.

Written by the indexing model from the issue text.