[wasi][coreCLR] Exception rethrow stack-line tests fail under the wasm interpreter

[lewing]

Summary

On the CoreCLR-WASI library-test leg (#130129), two System.Runtime.Tests exception tests fail because the interpreter reports different stack-line information than the JIT:

• System.Tests.ExceptionTests.ThrowStatementDoesNotResetExceptionStackLineSameMethod
• System.Tests.ExceptionTests.ThrowStatementDoesNotResetExceptionStackLineOtherMethod

Both assert (via VerifyCallStack) that a rethrow (throw;) preserves the original throw's source line in Exception.StackTrace. Under the CoreCLR wasm interpreter the reported line/frame differs, so the assert fails:

Assert.True() Failure
Expected: True
Actual:   False
   at System.Tests.ExceptionTests.VerifyCallStack(...)
   at System.Tests.ExceptionTests.ThrowStatementDoesNotResetExceptionStackLine{Same,Other}Method()

These are [ConditionalFact(HasAssemblyFiles)]. On browser wasm HasAssemblyFiles is false so they skip; on wasi the bundle has real .dlls so HasAssemblyFiles is true and they run and fail. They're already [ActiveIssue]'d for Mono and Apple-mobile CoreCLR for related reasons.

Disposition

Marking these [ActiveIssue(..., IsWasi, IsCoreCLR)] on the bring-up leg. This tracks a real interpreter stack-line/EH-metadata difference to fix in the CoreCLR wasm interpreter.

Related: #130129 (CoreCLR-WASI library tests). The RuntimeFeature.DynamicCode_Jit failure on the same leg is the interp-has-no-JIT case, tracked by #123011.

Note

This issue was drafted with GitHub Copilot.

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke
See info in area-owners.md if you want to be subscribed.