[release/10.0] Backport #127638: Fix !m_RedirectContextInUse assert in RestoreContextSimulated on win-x86

### Summary

This is a request to backport **PR #127638** to the `release/10.0` branch so it ships in a future .NET 10 servicing update.

The original bug is tracked in #127637 (now closed). The fix was merged to `main` on 2026-05-01 (merge commit `bd9e85e4b37557e649fccc083f33a50acdda2dde`) but has **not** been backported to `release/10.0`. I verified that `v10.0.8`, `v10.0.9`, and `v10.0.10` all still contain the buggy code:

- `Thread::RestoreContextSimulated` still calls `HandleThreadAbort()` while `m_RedirectContextInUse` is `true`
- The x86 `RestoreContextSimulated` call still happens **before** `COMPlusCheckForAbort()`

### Why this matters

This is not just a Windows 7 compatibility issue. The root cause is a **correctness bug in the x86 `RestoreContextSimulated` path** that can affect **any x86 .NET 10 process** running in an environment where `RtlRestoreContext` is unavailable in `ntdll.dll` (x86 Win7, WOW64 on Win7, and potentially other setups).

The double-redirect race silently corrupts the saved thread context and causes **random, hard-to-diagnose crashes** — exactly the kind of issue that LTS users will hit in production.

### Why it's safe to backport

- The change is minimal: **+10 / -12 lines** in a single file (`src/coreclr/vm/threadsuspend.cpp`)
- It only reorders the abort check before the context-restore call and removes the inlined `HandleThreadAbort()` from `RestoreContextSimulated`
- It was authored/reviewed by the runtime team (jkotas) and is already live on `main`

### Request

Could this please be backported to `release/10.0` for an upcoming servicing release? .NET 10 is an LTS release supported through November 2028, so a large number of users will remain on it for years.

Related:
- Original issue: #127637
- Fix PR (merged to main): #127638