react-scan 0.5.x floats react-grab and react-doctor on the "latest" dist-tag, making resolutions non-reproducible

## Description

`react-scan@0.5.x` declares two of its dependencies with the `latest` dist-tag rather than a semver range:

```jsonc
// react-scan@0.5.7
"dependencies": {
"react-doctor": "latest",
"react-grab": "latest"
}
```

`react-grab` has been `latest` since 0.5.5, and `react-doctor` was added the same way in 0.5.7.

Because `latest` is a moving target, the resolved transitive tree depends on the day you install rather than on the version of `react-scan` you asked for. `react-scan@0.5.7` installed in May and `react-scan@0.5.7` installed today are different dependency graphs.

## Why this matters

**Reproducibility.** A lockfile protects a project that already has one, but it does not help a fresh `npm i react-scan`, a lockfile regeneration, a bot-driven re-resolution, or anyone reproducing a bug report. #467 illustrates this: the reporter's environment lists `react-grab: 0.1.37`, while `latest` today is `0.1.50`. Two people following identical steps get different trees, which makes triage harder than it needs to be.

**Release cadence makes the window wide.** `react-grab` has 146 stable releases (269 including prereleases), 18 of them in the last 90 days, with the most recent on 2026-07-23. `react-doctor` has 624 published versions, most recent 2026-07-25. These are not dormant packages where a floating tag would be harmless.

**Supply chain gating.** pnpm 11 enforces a `minimumReleaseAge` policy by default, holding back packages published within the last 24 hours. A dependency floating on `latest` is exactly the pattern that policy exists to catch, since a routine install can pull code published minutes earlier with no review and no changelog the consumer ever sees. Teams running that gate, or an equivalent policy, hit friction on `react-scan` that they do not hit on its peers.

**There is already an implied compatibility contract.** `react-scan` warns at runtime when the resolved `react-grab` is behind, as reported in #461:

```
[React Scan] react-grab v0.1.32 is outdated (latest: v0.1.44).
Update react-scan to pick up the newer react-grab
```

So a version relationship between the two packages is being asserted, it just is not expressed anywhere npm can act on. That check is also the code path that produces the `REACT_GRAB_VERSION` import in #467 and #447.

## Suggested fix

Declare normal ranges and let the existing runtime check handle the "a newer one is out" nudge:

```jsonc
"dependencies": {
"react-doctor": "^0.9.1",
"react-grab": "^0.1.50"
}
```

Consumers still pick up compatible updates automatically, the resolution becomes a function of the `react-scan` version alone, and each bump becomes visible in a changelog and a diff. If the two packages really must move in lockstep, exact pins bumped by release tooling would express that more honestly than `latest`.

## Environment

Encountered while triaging a dependency bump on a public Next.js app ([disscount.me](https://disscount.me), source at https://github.com/OffCrazyFreak/Disscount).

- react-scan: 0.5.7
- next: 16.2.11
- node: 22.19.0
- pnpm: 11.9.0

This is separate from #467 and #447, which are about the JSON named import specifically. Fixing those does not change the floating-tag behaviour, and fixing this does not fix those.