Wisp 2.6.12: GPU priority setting, tune results kept, exit and clip hardening

[Views2k]

Since the 2.4 performance hotfix (#91) the native renderer raised the process GPU scheduling class to HIGH and the device thread priority to +1 at every hardware device creation, so the overlay's presents preempt the game's GPU work on every frame. A support report on 2.6.8 (Xbox app, RX 6950 XT, 1440p 240 Hz, clips off) matches that mechanism: 120 to 60-80 fps, brief stutter and 1-2 s audio glitches while Wisp is on screen, recovering after a pause.

This release candidate (2.6.12) makes the elevation a setting, off by default: "Prioritize HUD updates on the GPU" in HUD settings next to CPU rendering. Renderer creation never sets a priority; the new WispRendererSetGpuPriority export raises HIGH / +1 or restores NORMAL / 0 on the render thread, and the worker applies the choice whenever it changes. The choice is reported to Tools as hudGpuPriority and can be paused from Feature controls as gpu-priority (wisp-site #250, live).

Also in this change:

• Tune performance results read from Forza's Tune screen stay with the current tune after the screen closes (same car, parts and settings), instead of disappearing on the next refresh.
• Feature control policies report to Tools when a revision is applied (feature/app/apply) and when one is rejected or cannot be cached, so a pause can be verified end to end.
• Application exit bounds its waits (10 s controller, 2 s activation listener, 3 s needle thread) so a stuck driver call cannot keep the process alive.
• Clip-page commands catch their own failures and refuse re-entry.
• Version 2.6.12 with release notes.

Steam: same renderer and tune paths; no platform-specific code touched. Xbox / Microsoft Store: same; the report that motivated the GPU change came from the Store build.

Verified: native contract tests cover creation, raise and restore; managed tests cover defaults, round trip, view model states, the Tools projection, the feature catalog and the tune carry-forward. Not verified here: no Windows build on the VM, so CI compiles and tests it; the gameplay A/B on the test installer is still needed before release.

[Views2k]

Release evidence for 2.6.12

Native renderer contract tests ran on the owner's Windows desktop (hardware GPU, 240 Hz display) at commit 2d7dc43 (tree a2a67ce0, the same tree the squash merge publishes):

.\src\Wisp.NativeRenderer\Build-NativeRenderer.ps1 -RunContractTests
{"contractFailures":0,"cpuRendering":false,"testWindowShown":true}
gpuPriorityAttempted=1;processEffective=2;deviceEffective=0
gpuPriorityToggleRaise=0x00000000;restoreProcessSet=0x00000000
pacingSeconds=3.001;displayHz=240;submittedPerSecond=240.292;timeouts=0

Not run for this release: live Steam and Xbox gameplay checks of the GPU priority setting (off by default) and the tune carry-forward. Published on the owner's instruction with those checks outstanding.