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

## 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 `.dll`s 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.

Start with the named System.Tests.ExceptionTests methods and inspect their existing ConditionalFact and ActiveIssue attributes. Mark the WASI/CoreCLR interpreter failures as described, then run the relevant System.Runtime.Tests WASI test leg and confirm these tests are tracked as active issues rather than unexpected failures.

Written by the indexing model from the issue text.