Update test framework mock paths during file rename operations

Personne n'a encore pris cette issue.

### 🔍 Search Terms

All searched terms
"jest"
"mock"
"vitest"
"filename"
"rename" (this is NOT a rename default export when file name changes request)

### ✅ Viability Checklist

- [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [x] This wouldn't change the runtime behavior of existing JavaScript code
- [x] This could be implemented without emitting different JS based on the types of the expressions
- [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [x] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [x] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

When renaming or moving files in TypeScript projects, the language service should automatically update string literal paths in test framework mocking functions (e.g., `jest.mock()`, `vitest.mock()`) in addition to standard import statements.

## Use Cases

When you rename/move a file, TypeScript updates imports but **not** mock paths:

```typescript
// Before renaming helper.ts → utils/helper.ts
import { helper } from "./helper";
jest.mock("./helper"); // ❌ Not updated - breaks tests!

// After rename
import { helper } from "./utils/helper"; // ✅ Updated automatically
jest.mock("./helper"); // ❌ Still points to old location - test fails
```

This leads to:
- Broken tests after refactoring
- Manual find-and-replace operations
- Time wasted tracking down test failures
- More tedium when reorganizing code structure

### Desired Behavior

After renaming/moving a file, **both** imports and mock paths should update:

```typescript
// Before renaming helper.ts → utils/helper.ts
import { helper } from "./helper";
jest.mock("./helper");

// After rename
import { helper } from "./utils/helper"; // ✅ Updated
jest.mock("./utils/helper"); // ✅ Also updated!
```

## Examples

### Jest Patterns
```typescript
jest.mock("../services/api");
jest.unmock("../services/api");
jest.requireActual("../services/api");
jest.requireMock("../services/api");
jest.doMock("../services/api");
jest.dontMock("../services/api");
```

### Vitest Patterns
```typescript
vitest.mock("../services/api");
vi.mock("../services/api");
```

### Dynamic Imports & Require
```typescript
const module = await import("../services/api");
const module = require("../services/api");
```

## Expected Behavior

1. When a file is renamed/moved via IDE operations (F2, drag-drop, etc.)
2. TypeScript should scan all files for references to the old path
3. Update **all** string literals that reference the file, including:
- Standard `import`/`export` statements (already works)
- `jest.mock()` and related Jest functions
- `vitest.mock()` and related Vitest functions
- `require()` calls
- Dynamic `import()` expressions
4. Only update relative paths that actually point to the renamed file
5. Skip non-local modules (npm packages)

## Workarounds

Currently, developers must:
1. Rename the file
2. Manually find all test files that mock it
3. Update each mock path by hand
4. Hope they didn't miss any

## Additional Context

- This affects large codebases more severely (more mocks = more manual work)
- Common in projects with comprehensive test coverage
- Similar features exist in other IDEs (e.g., WebStorm handles this)
- Would significantly improve refactoring experience in test-heavy projects

## Proposed Solution

Add an opt-in preference (e.g., `updateImportsInTestFrameworkCalls`) that enables this behavior. The feature should:
- Be conservative (only update simple patterns)
- Be extensible (easy to add support for new test frameworks)
- Avoid false positives (only update actual file references)
- Work with both JavaScript and TypeScript files

## Alignment with TypeScript Goals

This feature aligns with TypeScript's core design goals:

1. **"Statically identify constructs that are likely to be errors"**
- Outdated mock paths after file renames are errors that TypeScript can detect and prevent
- Currently these errors only surface at test runtime, this would catch them during development

2. **"Provide a structuring mechanism for larger pieces of code"**
- Enables confident refactoring and code organization without fear of breaking tests
- Makes it easier to maintain well-structured codebases by removing friction from file reorganization

3. **"Be a cross-platform development tool"**
- Enhances the IDE/editor experience across all platforms
- Improves the TypeScript language service that powers multiple editors

4. **"Preserve runtime behavior of all JavaScript code"**
- This is purely a development-time tooling enhancement
- No changes to emitted code or runtime behavior
- Only updates source code strings to maintain correct runtime behavior after refactoring

## Affected Packages
- TypeScript Language Service
- VS Code TypeScript Extension (for preference exposure)

### 📃 Motivating Example

You're refactoring a large TypeScript project and decide to reorganize your file structure. You move `src/api/userService.ts` to `src/services/users/userService.ts`. TypeScript automatically updates all your imports:

```typescript
// Before
import { getUser } from '../../api/userService';
// After
import { getUser } from '../../services/users/userService'; ✅
```

Great! But then your tests start failing. You discover that TypeScript **didn't** update your test mocks:

```typescript
jest.mock('../../api/userService'); // ❌ Still points to old location!
```

You now have to manually search through dozens (or hundreds) of test files, find every `jest.mock()` call that references the moved file, and update each one by hand. This is tedious, error-prone, and makes refactoring feel risky.

**With this feature**, TypeScript would treat mock calls the same as imports:

```typescript
jest.mock('../../services/users/userService'); // ✅ Updated automatically!
```

Now you can confidently refactor your codebase knowing that both imports *and* mocks will stay in sync. Your tests keep passing, and you spend time improving code instead of hunting down broken references.

### 💻 Use Cases

1. What do you want to use this for?
Large refactors and more confidence in IDE tooling.
2. What shortcomings exist with current approaches?
This is not covered by the current version of TypeScript.
3. What workarounds are you using in the meantime?
When moving single files have to also search for all references to that files (or forget about that and have CI failing)
When moving folders I need to run the full suite to find where there might be file references that need a manual update.

Commencez par l’implémentation de rename/refactoring de TypeScript Language Service et ses tests existants de mise à jour des imports ; l’issue ne nomme aucun fichier ni point d’entrée de test spécifique. Comparez les cas demandés pour Jest, Vitest, require et dynamic import, puis établissez le périmètre pris en charge et le comportement de la préférence opt-in. Le travail est terminé lorsque les cas convenus mettent à jour uniquement les références relatives vers les fichiers renommés et sont couverts par des tests.

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