perf(migrate): Vitest signal detection repeatedly traverses package source trees

### Summary

During the full project rewrite path of `vp migrate`, the same package source tree is traversed synchronously multiple times to collect Vitest browser/provider signals.

Under the following full-miss conditions:

- the source contains no relevant Vitest browser/provider references;
- no tsconfig contains Vitest types that must be retained;
- package.json contains no webdriverio/provider dependency that causes an early return;

the Vitest signal-detection phase reads every eligible TS/JS file through Node.js `fs.readFileSync`:

- 5 times for a standalone project;
- 9 times for each workspace package in a monorepo.

These counts cover only the JavaScript-side Vitest signal scans. They do not represent all file I/O performed during migration. For example, the later Rust/NAPI import rewriter also traverses and reads source files, but those reads are not visible to an `fs.readFileSync` probe.

### Local reproduction

I created temporary test projects containing many small `.ts` files with no Vitest browser/provider references. Their package.json files also contained no dependencies that would cause the checks to return early.

I then monitored `fs.readFileSync` calls for those fixture source files and invoked the production migration entry points directly.

| Call path | Source files | Source reads through `fs.readFileSync` | Duration |
| --- | ---: | ---: | ---: |
| `rewriteStandaloneProject` | 5,000 | 25,000 | 486 ms |
| `rewriteMonorepo` (2 × 2,500 files) | 5,000 | 45,000 | 734 ms |

Environment: macOS, Node.js 25.9.0, with the filesystem cache pre-warmed.

The per-file read counts are deterministic: exactly 5 reads per file for the standalone project and exactly 9 reads per file for each monorepo workspace package. Every detection result was `false`, so each check took its complete miss path.

The timings are included only to illustrate the approximate impact and will vary between machines.

### Observed call paths

`sourceTreeMatches` recursively traverses directories with `readdirSync` and reads every TS/JS file with an eligible extension using `readFileSync`. It returns early only after finding a match, so a complete miss is the worst-case path.

#### Standalone

Within a single `rewriteStandaloneProject` call:

1. `collectProviderSourceModes` scans once for each of the two current opt-in providers: 2 passes;
2. `usesVitestBrowserMode` performs another scan: 1 pass;
3. `sourceTreeReferencesRetainedVitestModule` scans the source again: 1 pass;
4. when no webdriverio dependency causes a short circuit, `usesWebdriverioProvider` performs another scan: 1 pass.

This results in 5 reads per source file.

`providerSourceModes` already contains the webdriverio source-detection result, but the standalone path subsequently calls `usesWebdriverioProvider` anyway.

In addition, `sourceTreeReferencesRetainedVitestModule` first performs a separate recursive directory traversal to discover tsconfig files and reads any matching tsconfig files it finds. As a result, the package directory tree is traversed 6 times on a complete standalone miss, with 5 of those passes reading TS/JS source files.

#### Monorepo workspace package

`rewriteMonorepo` first computes workspace-level signals. For every workspace package on the complete miss path:

- `workspaceUsesWebdriverio`: 1 source scan;
- `workspaceUsesVitestDirectly`:
- retained Vitest module: 1 scan;
- browser mode: 1 scan;
- `collectInjectedProviderNames`:
- two provider scans: 2 scans.

The workspace phase therefore reads each source file 5 times.

The same package is then processed by `rewriteMonorepoProject`, which recomputes:

- browser mode: 1 scan;
- retained Vitest module: 1 scan;
- source modes for two providers: 2 scans.

The package phase adds another 4 reads, for a total of 9 reads per source file in each workspace package.

The monorepo root package is not subsequently passed through `rewriteMonorepoProject`, so source files belonging directly to the root package are generally read 5 times rather than 9.

The two retained-module checks also each add a separate directory-tree traversal for locating tsconfig files. A workspace package therefore undergoes 11 related full directory-tree traversals on the complete miss path, 9 of which read TS/JS source files.

### Reusing scan results

In the reproduction projects above, no source files were modified between these scans in a way that could affect the results.

In the general monorepo path, however, `rewriteMonorepoProject` performs configuration merging before the package-level scans. That step may create or modify `vite.config.ts`. Reusing results between the workspace and package phases would therefore require confirming that these configuration changes cannot affect the relevant signals, or retaining the two phases while consolidating the scans performed within each phase.

Regardless of whether results can be cached across phases, each individual phase currently performs separate full traversals for several closely related boolean signals.

### Impact

The complete miss path remains linear in the number of files, but it has a fixed synchronous I/O amplification:

- standalone package: 5 reads per eligible source file;
- monorepo workspace package: 9 reads per eligible source file.

These directory traversals and file reads are synchronous and directly block `vp migrate`. The cost becomes noticeable in projects containing thousands or tens of thousands of source files.

Ideally, browser mode, retained Vitest module references, and provider signals could be collected during a single source-tree traversal, with the resulting scan data shared by callers within the same migration phase.

Commencez par rewriteStandaloneProject, rewriteMonorepo et rewriteMonorepoProject, puis suivez sourceTreeMatches, collectProviderSourceModes, usesVitestBrowserMode, sourceTreeReferencesRetainedVitestModule et usesWebdriverioProvider. Comparez les phases workspace et package, notamment la fusion des configurations, et regroupez la collecte des signaux compatibles au sein de chaque phase sans modifier le comportement des retours anticipés. Le travail est terminé lorsque les chemins d'absence complète évitent les lectures redondantes de l'arbre source tout en préservant tous les résultats de détection.

Rédigé par le modèle d'indexation à partir du texte de l'issue.