Fix ARM64 ThreadAbort issue

[janvorli]

There is a problem with RtlRestoreContext not restoring context during thread abort if that abort comes from injected APC callback on ARM64 and the processor supports SVE. In that case, the context provided by the APC callback can contain XSTATE and when we start walking stack from that context, we copy that context into the REGDISPLAY. The problem is that we copy the ContextFlags without changes, so if they contained CONTEXT_XSTATE flag, it is kept set even though the REGDISPLAY has only plain old CONTEXT without any XSTATE.
When we call RtlRestoreContext in the ResumeAfterCatch, it fails because the XSTATE is not valid and so it returns. That's unexpected and we end up crashing with an assert.

The fix clears the CONTEXT_XSTATE in ResumableFrame::UpdateRegDisplay so that the REGDISPLAY's contexts ContextFlags are validly representing the context stored in the REGDISPLAY.

Close #120437

[Copilot]

Pull Request Overview

This PR fixes a ThreadAbort issue on ARM64 processors with SVE support where RtlRestoreContext fails during thread abort recovery. The issue occurs when an APC callback provides a context with XSTATE flags that are copied to a REGDISPLAY without the corresponding XSTATE data, causing RtlRestoreContext to fail.

• Clears invalid CONTEXT_XSTATE flags in ResumableFrame::UpdateRegDisplay_Impl for both ARM64 and AMD64
• Adds UNREACHABLE() marker after RtlRestoreContext call to indicate expected control flow
• Ensures ContextFlags accurately represent the actual context data stored in REGDISPLAY

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/coreclr/vm/threads.cpp	Adds UNREACHABLE() after RtlRestoreContext call
src/coreclr/vm/arm64/stubs.cpp	Clears CONTEXT_XSTATE flags in ARM64 ResumableFrame implementation
src/coreclr/vm/amd64/cgenamd64.cpp	Clears CONTEXT_XSTATE flags in AMD64 ResumableFrame implementation

[janvorli]

/azp run runtime-coreclr libraries-jitstress

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jkotas]

Backport candidate?

[janvorli]

Backport candidate?

Yes

[janvorli]

There is a couple of failing System.Net.XXX tests. All of the failures in these tests are asserting on

Assertion failed.
Interop.Sys.LSeek(this, 0, Interop.Sys.SeekWhence.SEEK_CUR) >= 0
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String fullPath, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, UnixFileMode openPermissions, Int64& fileLength, UnixFileMode& filePermissions, Boolean failForSymlink, Boolean& wasSymlink, Func`4 createOpenException) in /_/src/libraries/System.Private.CoreLib/src/Microsoft/Win32/SafeHandles/SafeFileHandle.Unix.cs:line 208
   at System.IO.Strategies.OSFileStreamStrategy..ctor(String path, FileMode mode, FileAccess access, FileShare share, FileOptions options, Int64 preallocationSize, Nullable`1 unixCreateMode) in /_/src/libraries/System.Private.CoreLib/src/System/IO/Strategies/OSFileStreamStrategy.cs:line 46
etc...

[janvorli]

/ba-g test failures are #120577

[janvorli]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0: https://github.com/dotnet/runtime/actions/runs/18388537629