MoAppHang in Windows Terminal 1.24 on Intel Iris Xe driver 32.0.101.7082

# Windows Terminal 1.24 MoAppHang on Intel Iris Xe driver 32.0.101.7082

### Windows Terminal version

1.24.11321.0

WER also reports application version `1.24.2605.12001`.

### Windows build number

10.0.26200.8737

### Other Software

- GPU: Intel(R) Iris(R) Xe Graphics
- GPU driver: `32.0.101.7082`
- GPU device id: `PCI\VEN_8086&DEV_46A8&SUBSYS_3B3A17AA&REV_0C`
- Shells/tools active around the event included PowerShell/Git Bash/Node-based CLI work.
- Third-party modules observed in the WER loaded-module list: `FencesMenu64.dll`, `weasel.dll`.
- Windows Terminal settings included:

```json
"rendering": {
"graphicsAPI": "direct2d"
}
```

### Steps to reproduce

I do not have a deterministic minimal repro yet.

The captured failure occurred during normal Windows Terminal use with multiple CLI sessions. Immediately before the investigation, a Node/V8 child process in a terminal tab printed an out-of-memory failure:

```text
FATAL ERROR: Zone Allocation failed - process out of memory
```

After the terminal stopped responding, Windows Error Reporting recorded a `MoAppHang` for Windows Terminal.

### Expected Behavior

A child process failure or a graphics-driver/rendering issue should not make the Windows Terminal host hang and get closed by Windows Error Reporting. At worst, the affected tab/process should fail while the host remains responsive.

### Actual Behavior

Windows Terminal became unresponsive and Windows closed it as an application hang.

Relevant local Event Viewer/WER details:

```text
Event source: Windows Error Reporting
Event name: MoAppHang
ReportIdentifier: 3ba9ac6a-02a6-447e-aab6-4e546fc32b25
IntegratorReportIdentifier: 21f223ee-64a0-48f3-a49b-d5045ff77679
Package: Microsoft.WindowsTerminal_1.24.11321.0_x64__8wekyb3d8bbwe
Application Version: 1.24.2605.12001
Hang Signature: 76f3
Hang Type: 134234112
OS: 10.0.26200.8737
UI: Windows Terminal Host was not responding
```

The same WER report loaded Direct2D/DirectWrite/DXGI/D3D11 modules plus Intel graphics driver modules:

```text
d2d1.dll
DWrite.dll
dxgi.dll
d3d11.dll
igd10iumd64.dll
igd10um64xe.DLL
igdgmm2_64.dll
igdgmm64.dll
igc64.dll
```

I have not attached the full local WER report or dump publicly yet. The local WER report is available and I can provide a scrubbed copy or collect a Feedback Hub link if maintainers need backend diagnostics.

### Notes from duplicate/source checking

I searched for existing issues using variants around `MoAppHang`, `76f3`, `134234112`, `1.24.2605.12001`, `Intel Iris Xe`, and `32.0.101.7082`.

Related but not direct duplicates:

- #13569: older closed MoAppHang thread for Windows Terminal 1.13.
- #19727: closed intermittent hang case with a different driver/environment.
- #20269 and #20324: open access-violation crash reports, not the same WER hang signature.
- #15553: open issue about GPU driver updates/resets closing terminal windows.
- #17255: open startup failure, not this runtime hang.

I also checked current `main` source before filing because I saw a suggested MSAA/AtlasEngine root-cause hypothesis elsewhere. I do not want to claim that as the root cause: current `src/renderer/atlas/AtlasEngine.r.cpp` creates the swap chain with `SampleDesc.Count = 1`, and I did not find a `CheckMultisampleQualityLevels` path under `src/renderer`.

Start by reviewing the WER details and the rendering path in src/renderer/atlas/AtlasEngine.r.cpp, including the Direct2D, DXGI, and Intel driver context reported here. There is no deterministic reproduction, so first determine whether a scrubbed WER report, dump, or Feedback Hub link can narrow the cause. Done means identifying a reproducible failure or actionable diagnosis without assuming the MSAA hypothesis.

Written by the indexing model from the issue text.