Update test framework mock paths during file rename operations

まだ誰も着手していません。

### 🔍 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.

TypeScript Language Service の rename/refactoring 実装と既存の import 更新テストから始めます。この issue では、特定のファイルやテストのエントリーポイントは指定されていません。Jest、Vitest、require、dynamic import について要求されたケースを比較し、サポート対象の範囲と opt-in 設定の動作を確定します。合意したケースが、名前変更されたファイルへの相対参照のみを更新し、テストでカバーされていれば完了です。

索引モデルが issue の本文から書いたものです。