fix: point analyzer diagnostics to specific parameters instead of methods

[thomhurst]

Summary

• Analyzer diagnostics that are about specific parameter issues now point to the offending parameter's location rather than the method name, giving users more precise IDE feedback
• Applies the same pattern already used in CombinedDataSourceAnalyzer (parameter.Locations.FirstOrDefault() ?? context.Symbol.Locations.FirstOrDefault()) to seven other analyzers
• Method-level diagnostics (e.g., "must be static", "must be public") remain unchanged -- only parameter-specific diagnostics were updated

Analyzers updated:

• TimeoutCancellationTokenAnalyzer: points to last parameter when it is not CancellationToken
• GlobalTestHooksAnalyzer: points to first unknown parameter
• AssemblyTestHooksAnalyzer: points to first unknown parameter
• ClassHooksAnalyzer: points to first unknown parameter
• InstanceTestHooksAnalyzer: points to first unknown parameter
• MatrixAnalyzer: points to parameter with wrong matrix value type
• TestMethodParametersAnalyzer: points to first parameter needing a data source

Test plan

• Updated GlobalTestHooksAnalyzerTests to expect diagnostic at parameter location
• Updated TestMethodParametersAnalyzerTests to expect diagnostic at parameter location
• All updated tests pass on net9.0
• No existing tests for AssemblyTestHooksAnalyzer, ClassHooksAnalyzer, InstanceTestHooksAnalyzer (no test files exist)
• MatrixDataSourceAnalyzerTests pass (the changed diagnostic path has no dedicated test case)
• TimeoutCancellationTokenAnalyzerTests pass (no test covers the "last param is not CancellationToken" scenario)
• Build succeeds with zero errors

Closes #4899

[claude]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

The change is clean and well-executed. The pattern of using parameter.Locations.FirstOrDefault() ?? context.Symbol.Locations.FirstOrDefault() as a graceful fallback is consistent with the existing approach in CombinedDataSourceAnalyzer and handles the edge case where a parameter has no location (e.g., synthesized symbols) correctly.

A few observations worth noting:

• Consistency: GlobalTestHooksAnalyzer.FindFirstUnknownParameter correctly uses GloballyQualifiedNonGeneric() to match the existing CheckHookParameters method in that file, while the other analyzers use GloballyQualified() — this asymmetry is intentional and correct, not a bug.
• parameters[0] in TestMethodParametersAnalyzer: Safe — the early return on parameters.Length == 0 guards this access.
• FindFirstUnknownParameter returning null: Theoretically possible in edge cases (e.g., wrong parameter order like (CancellationToken, ClassHookContext) which CheckHookParameters rejects but FindFirstUnknownParameter considers "all known"), but the ?? fallback ensures correct behavior with no regression from the original.

Good improvement to developer experience — squiggles on the specific bad parameter rather than the whole method name is exactly the right UX.