fix: improve source generator diagnostic locations

[thomhurst]

Summary

• TestMetadataGenerator: Replace Location.None with the actual method symbol location so users can click the error and navigate directly to the failing test method declaration.
• HookMetadataGenerator: Include FilePath and LineNumber in the diagnostic message so users can find the hook method manually (the HookModel is a primitive model without Roslyn symbols, so a Location object cannot be constructed, but the file/line info is available).
• AotConverterGenerator: Improve error messages to include exception type names, messages, and conversion type context (SourceType/TargetType) so users can identify the problematic types.
• AotConverterGenerator: Add a broader catch (Exception) handler (excluding OperationCanceledException) in ScanTestParameters to wrap unexpected errors with context, preserving the original exception as InnerException.

Test plan

• dotnet build TUnit.Core.SourceGenerator/TUnit.Core.SourceGenerator.csproj passes with 0 warnings and 0 errors
• Verify that when a source generation error occurs in TestMetadataGenerator, the IDE error list shows the correct file/line location
• Verify that HookMetadataGenerator errors now include file path and line number in the message text
• Verify that AotConverterGenerator errors include actionable type information

Closes #4865

[claude]

Code review

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

The changes are well-scoped and targeted. A few highlights:

• TestMetadataGenerator.cs: Using testMethod?.MethodSymbol?.Locations.FirstOrDefault() ?? Location.None instead of Location.None is the right approach — IDE error navigation to the actual failing test method is a meaningful UX improvement.
• HookMetadataGenerator.cs: Embedding FilePath and LineNumber in the message text is the correct workaround given that HookModel is a primitive model without a Roslyn symbol, making it impossible to construct a proper Location object.
• AotConverterGenerator.cs: The broader catch (Exception ex) when (ex is not OperationCanceledException) guard is correct — the OperationCanceledException exclusion is an important detail to avoid swallowing cancellation signals. The message format placeholder counts all match their argument counts.

The PR correctly identifies that these are error-path-only changes (inside catch blocks and diagnostic reporting), so no snapshot test updates or dual-mode counterparts in TUnit.Engine are needed.