#967)

Improves `no-unnecessary-type-parameters` performance by avoiding the expensive recursive type-usage walk for type parameters that are already obviously safe to skip.

The rule already had an AST-based fast path:

 ```go
isTypeParameterRepeatedInAST(...)
```

but it ran after countTypeParameterUsage, which is the expensive checker-heavy part. This meant we were paying the full recursive type analysis cost even for type parameters that could be ruled out cheaply.

This PR moves that cheap filtering earlier, then narrows the expensive pass to only the remaining candidates.

## Why This Is Faster

The slow path is countTypeParameterUsage, which recursively walks TypeScript types and calls into the checker. On large projects like VS Code, most generic declarations are not reportable because their type parameters are used more than once in the signature.

Before this change, the rule did this for every generic declaration:

 1. recursively count type parameter usage with checker types
 2. collect AST references
 3. skip if the AST already proves the type parameter is repeated

That order wastes work. If the AST can prove the type parameter appears multiple times before the function body, then the rule will not report it, so there is no reason to do the recursive checker walk first.

After this change, the rule does this instead:

 1. collect AST references
 2. keep only type parameters that are still possible reports
 3. recursively count usage only for those candidates
 4. stop counting once every candidate has exceeded the reportable threshold

This keeps the same behavior, but avoids a lot of type-checker and map work on declarations that are never going to produce diagnostics.

## Benchmark

Measured with a shallow clone of microsoft/vscode, using 6,187 src/**/*.ts(x) files through local tsgolint headless.

Environment:

- rule: no-unnecessary-type-parameters

Hyperfine, 3 runs:

| Binary | Mean | User | System |
| --- | ---: | ---: | ---: |
| baseline | 11.333s ± 0.061s | 43.635s | 0.992s |
| patched | 4.002s ± 0.078s | 14.775s | 0.570s |

That is a 2.83x speedup for this isolated rule workload.

fixes #961