[BUG] amdgpu TTM eviction livelock causes multi-second desktop freezes during Proton gaming (RX 9070 XT)

## Summary

Multi-second desktop freezes during Proton gaming on RX 9070 XT. `journalctl` logs nothing. The freeze traces to a growing pileup of `kworker/uXX:N+ttm` threads stuck in D-state. amdgpu's buffer-object eviction path livelocks under GPU memory pressure. Reproducible on `7.1.3-1-cachyos`. Not reproduced yet on `6.18.37-1-cachyos-lts` after a full session.

## System

- CPU: AMD Ryzen 7 9800X3D (single CCD)
- GPU: RX 9070 XT, 16GB VRAM (RDNA4)
- Kernel: `7.1.3-1-cachyos` (broken), `6.18.37-1-cachyos-lts` (holds so far)
- Mesa: 26.1.4
- DE: KDE Plasma, Wayland
- Bootloader: Limine

## Symptom

The whole desktop freezes for several seconds, cursor included, then resumes. Sometimes it freezes, plays a fraction of a second of motion, then freezes again, repeating several times before recovering. Only observed under Proton/Wine (Steam Proton and `umu-run` via Lutris). No native Linux game has triggered it so far.

## Reproduction

- RuneScape 3 (Steam, appid 1343400), running on this distro's own Proton build (`CachyOS-11.0-100`)
- SP Football Life 2026 (Lutris, via `umu-run`)

Both are Wine/Proton games; that's the only thing they share. GPU stays at 100% busy with stable clocks/temps/VRAM through the freeze. This isn't a GPU hang or reset: `journalctl -b` shows zero amdgpu reset/timeout/fault events across the whole boot.

## Evidence

Wrote a small sampler (`ps -eo pid,stat,wchan,comm` every 0.2s, logging only D-state processes) and caught two incidents:

**Incident 1**, 2026-07-10, ~4.4s, 3 `+ttm` kworkers stuck the whole time:
```
11:41:57.144 77202 D< - kworker/u65:2+ttm
11:41:57.144 73477 D< - kworker/u65:0+ttm
11:41:57.144 56156 D< - kworker/u65:8+ttm
... (continuous, same 3 PIDs, every 0.2s sample, no gaps)
11:42:01.518 77202 D< - kworker/u65:2+ttm
```

**Incident 2**, 2026-07-14, ~9.4s, growing from 3 to 12 simultaneous stuck `+ttm` kworkers, then all clearing at once:
```
11:51:32.943 4991 D< - kworker/u65:8+ttm
11:51:32.943 4367 D< - kworker/u65:4+ttm
11:51:32.943 144 D< - kworker/u65:0+ttm
... (count grows every few samples)
11:51:38.982 5933 D< - kworker/u65:13+ttm
11:51:38.982 5931 D< - kworker/u65:11+ttm
11:51:38.982 5476 D< - kworker/u65:10+ttm
11:51:38.982 5475 D< - kworker/u65:9+ttm
11:51:38.982 4991 D< - kworker/u65:8+ttm
11:51:38.982 4990 D< - kworker/u65:7+ttm
11:51:38.982 4369 D< - kworker/u65:6+ttm
11:51:38.982 4368 D< - kworker/u65:5+ttm
11:51:38.982 4367 D< - kworker/u65:4+ttm
11:51:38.982 1235 D< - kworker/u65:3+ttm
11:51:38.982 541 D< - kworker/u65:1+ttm
11:51:38.982 144 D< - kworker/u65:0+ttm
... (12 threads pinned, unchanged, until 11:51:42.106)
11:51:42.941 -- no ttm entries; all cleared simultaneously
```

The growth pattern in incident 2 (3 → 12 stuck workers, none clearing until the very end) matches the known amdgpu eviction livelock shape: an application keeps submitting new work while eviction is in progress, buffers get pulled back into VRAM mid-eviction, and the eviction never completes until submission pressure eases. VRAM sat at 4.5GB/16GB at idle checks, so this isn't simple oversubscription. The eviction mechanism itself is stalling under load, not hitting a capacity ceiling.

## Ruled out

- `plasma-foreground-booster` / `dmemcg-booster` (CPU-weight and VRAM-cgroup boosters): fully masked, freeze still occurred.
- PCIe ASPM / NVMe autosuspend / amdgpu runtime PM: `amdgpu.aspm=0 amdgpu.bapm=0 amdgpu.runpm=0` applied and confirmed live, freeze still occurred.
- Display-core debug path: `amdgpu.dcdebugmask=0x10` applied and confirmed live, freeze still occurred (9.4s incident above happened with this active).
- amdgpu reset/hang: zero reset/timeout/fault kernel log entries across boots where freezes occurred.
- Dual-CCD scheduler bouncing: N/A, this CPU has a single CCD.
- PipeWire audio underruns: none logged, quantum settings at default.

## Kernel comparison

Same "broken on 7.1.x, fine on LTS" pattern shows up in #920 (ACPI EC worker hangs, different subsystem, ASUS Zenbook) and #901 (CPU+memory-load crashes, closed). This report hits the same regression window but a different stuck subsystem: amdgpu TTM rather than ACPI EC or amd_pstate. It may be a separate bug, or a shared root cause further down in the scheduler/workqueue layer. Flagging both in case they're related.

## Notes

Will keep gaming on LTS and report back if the freeze reproduces there too.

No source file or test is named. Start by reproducing the freeze on 7.1.3-1-cachyos and comparing it with 6.18.37-1-cachyos-lts, then trace the amdgpu TTM eviction path and the stuck +ttm workqueue workers under Proton load. Done means identifying the eviction livelock cause and confirming that the desktop no longer freezes during the listed reproductions.

Written by the indexing model from the issue text.