Type Inference Enhancement of Handler Args

Nobody has claimed this yet.

### 🔍 Search Terms

"type inference", "type narrowing"

### ✅ 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

# Introduction

When I write React codes with TypeScript, I sometimes define Props as the following.

```typescript
type Props = ({
parentIds: string[];
onChange: (event: { id: string }) => void
onChange2: () => void
} | {
parentIds?: never;
onChange: (event: { id: number }) => void;
})
```

It says, "When parentId is passed, string id is passed to onChange handler and you can use onChange2. If it is not passed, number is is passed to onChange handler".

But it doesn't work correctly. When I use it, as the following

```
function Component(props: Props) {
return null
}

function App() {
return (
{
if (e.id) {
// Do nothing
} else {
// Do nothing
}
}}
onChange2={() => {
console.log("parentId is detected as string[]")
}}
/>
)
}
```

The parameter `e` of onChange is inferred as `any`, not `{ id: string }`.
I can pass onChange2 handler so it seems type narrowing works, but type inference of the args of handler doesn't work.

# Suggestion
How about enhancing type inference in such case?

demo:
https://www.typescriptlang.org/play/?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgIilQ3wChSYBPMJOABRzAGc4BeOACgG9S44wURAHYwAkgBMAXHCYwowIQHMA2gF0A3LzgQhAYQAWKJUmkckANyQjpXOMCky5CxXAC+ASjYA+OOYj2tHQMjRSQAJlNPVh8-ANc4AB84Hj4BYTFxAH5pIQskKE0+IMNjUzzrZLsHIQBXEAAjfLcomP9xTQ9yTBqhDGAdOAA5HQBxK3zgNF1cSFyRDjBGJmkGCGZPFLgiGBqoIThagBtD0lcunr6BgEEwMA4NrW3d-Y4+N-ePz6-PrT4AHmGQjGuXkUxmOis8F+bzSkIkrC4ajOnwA9Ci4ABRAAeNAwSAcdEEKBASBgTVowBYtns0lk8iUbmhfDRcCuGBqKEOKyJJLJUDgAHIkAK7OBDpNgDBDpQ4IYWEZBUZKCKqDQAHQcADsAAZtQA2dxM7R6EqhBG0aLJI18YCYThINX2B7fZnogAiEAOEBg+mc1rccCQhyYtE23xZHq9Pr932RH1ccfexRC4QR928Vu+aB0TAghwdhwgig4+FhIgkdhY4lJSDx4jgKBYdOcanwhs+CehKK8WkNriAA

### 📃 Motivating Example

When you want to use same function or component for various purposes.

### 💻 Use Cases

1. What do you want to use this for?
2. What shortcomings exist with current approaches?
3. What workarounds are you using in the meantime?

Reproduce the linked TypeScript Playground example and confirm the implicit-any diagnostic (7006) for the handler parameter. No source file or test is named, so first locate the type-inference and contextual-typing entry points, then establish tests showing that the parameter is inferred as { id: string } while preserving the existing narrowing behavior.

Written by the indexing model from the issue text.