feat(valid-expect): support using typechecking to ensure toThrow type assertions are passed a function

[G-Rath]

Resolves #1329

[Copilot]

Pull request overview

Adds an optional type-aware enhancement to jest/valid-expect so that, when enabled, toThrow* matchers require expect() to be passed a callable (addressing #1329).

Changes:

• Add a typecheck option to valid-expect and, when enabled, use TypeScript parser services to validate toThrow* inputs are callable.
• Add type-aware test coverage for the new option, including “optional dependency” behavior checks.
• Document the new typecheck option in the rule docs.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/rules/valid-expect.ts	Introduces typecheck option and type-based callable validation for toThrow* matchers.
src/rules/__tests__/valid-expect.test.ts	Adds tests for the new typecheck behavior and its dependency/type-info requirements.
docs/rules/valid-expect.md	Documents the new typecheck option and its requirement for TS type information.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The autofix currently only inserts '() => ' before the expect(...) argument. That can produce invalid syntax (e.g. if the argument is an await/yield expression) and can also change parsing/meaning due to operator precedence (e.g. sequence expressions) or object-literal vs block-body ambiguity. Consider making the fix more robust by (a) bailing out for AwaitExpression/YieldExpression (and similar cases), and (b) wrapping the original argument in parentheses via a paired insertTextBefore/insertTextAfter (or using a block body with return) so the resulting code always parses as intended.