[Mono] StackTraceHelper tests fail on Mono due to generic type parameter differences

## Summary

6 StackTraceHelper tests fail on Mono because of differences in how generic type parameters are represented in stack traces compared to CoreCLR.

## Environment

- **Runtime**: Mono on x64/ppc64le/s390x (RHEL 10)
- **Target Framework**: net10.0
- **Test Project**: `Microsoft.AspNetCore.Shared.Tests`

## Failing Tests

### 1. `StackTraceHelper_PrettyPrintsStackTraceForGenericMethods`
```
Assert.Equal() Failure: Strings differ
↓ (pos 65)
Expected: ···"ckTraceHelperTest.GenericMethod(T val)"
Actual: ···"perTest.GenericMethod(string val)"
↑ (pos 65)
```

### 2. `StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericOutParameters`
```
Assert.Equal() Failure: Strings differ
↓ (pos 81)
Expected: ···"GenericOutParameter(string a, out T"···
Actual: ···"GenericOutParameter(string a, out in"···
↑ (pos 81)
```

### 3. `StackTraceHelper_PrettyPrintsStackTraceForMethodsOnGenericTypes`
```
Assert.Equal() Failure: Strings differ
↓ (pos 64)
Expected: ···"erTest+GenericClass.Throw(T parameter)"
Actual: ···"erTest+GenericClass.Throw(int parame"···
↑ (pos 64)
```

### 4. `StackTraceHelper_PrettyPrintsStackTraceForMethodsWithGenericRefParameters`
```
Assert.Equal() Failure: Strings differ
↓ (pos 81)
Expected: ···"GenericRefParameter(ref TVal value)"
Actual: ···"thGenericRefParameter(ref int value)"
↑ (pos 81)
```

### 5. `StackTraceHelper_ProducesReadableOutput`
```
Assert.Equal() Failure: Collections differ
↓ (pos 2)
Expected: List ["Microsoft.Extensions.Internal.StackTraceHelperTest"···, ...]
Actual: string[] ["Microsoft.Extensions.Internal.StackTraceHelperTest"···, ...]
↑ (pos 2)
```

### 6. `GetFrames_DoesNotFailForDynamicallyGeneratedAssemblies`
```
Assert.StartsWith() Failure: String start does not match
String: "object.lambda_method34(Closure )"
Expected start: "lambda_method"
```

## Behavior Difference

### On CoreCLR (Working)
- Generic methods show: `GenericMethod(T val)`
- Generic type methods show: `GenericClass.Method(T param)`
- Lambda methods show: `lambda_method34(Closure )`

### On Mono (Failing)
- Generic methods show: `GenericMethod(string val)` (concrete types)
- Generic type methods show: `GenericClass.Method(int param)` (concrete types)
- Lambda methods show: `object.lambda_method34(Closure )` (includes declaring type)

## Test Results Summary

- **CoreCLR**: 13 total, 13 passed, 0 failed
- **Mono**: 13 total, 7 passed, 6 failed

## Root Cause

The issue appears to be that Mono's reflection APIs return "inflated" generic types in stack frames, showing the concrete types that were used at runtime (`string`, `int`) instead of the generic type parameters (`T`, `TVal`) that CoreCLR preserves.

This affects:
- `MethodBase.GetGenericArguments()`
- Parameter type information from `ParameterInfo.ParameterType`
- Method names in dynamically generated assemblies

### Expected Behavior

_No response_

### Steps To Reproduce

_No response_

### Exceptions (if any)

_No response_

### .NET Version

_No response_

### Anything else?

_No response_

Start in the Microsoft.AspNetCore.Shared.Tests StackTraceHelper tests, especially the six named failing tests, and run them on both Mono and CoreCLR to compare stack-frame and generic-parameter representations. Trace StackTraceHelper and the reflection values used by these tests. Done means the six tests pass on Mono while the existing CoreCLR expectations remain valid.

Written by the indexing model from the issue text.