…ayDirty() (#3338) (#3411)

## Problem

The 9 spot-display setters in `SpectrumWidget.h` call `update()`, which
on the GPU path reuses the cached `m_overlayStatic` chrome texture
without re-baking it. `drawSpotMarkers()` never re-runs, so toggling
**Spot Lines** (or changing spot font size, start %, colours, etc.) has
no immediate visual effect — the change only takes hold when something
else triggers `markOverlayDirty()` (e.g. a new incoming spot).

This regression was introduced by #3124 (GPU path caches the chrome
overlay) and became consistently visible after #3299 (discrete GPU
preference on Windows) caused more users to hit the GPU path.

## Fix

Replace `update()` with `markOverlayDirty()` in all 9 setters.
`markOverlayDirty()` calls `update()` internally — identical behaviour
on the CPU path, correct invalidation on the GPU path.

All other display setters in the file (background opacity, MQTT display,
prop forecast, etc.) already use `markOverlayDirty()`. The spot setters
were the only outliers.

## Testing

Verified build compiles cleanly on macOS. GPU-path visual verification
(toggle Spot Lines with spots visible → lines appear/disappear
immediately) requires Windows with discrete GPU — the reporter in #3338
should be able to confirm.

Fixes #3338

…hersdr#3299)

## Summary

Fixes aethersdr#1921 — `STATUS_STACK_BUFFER_OVERRUN` crash on every pop-out
attempt on Windows hybrid-GPU laptops (Intel iGPU + discrete NVIDIA/AMD
GPU).

### Root cause

Intel's D3D11 user-mode driver (`igd10um64xe.dll`) corrupts its own
stack during `UpdateSubresource`, called from `QRhi::endOffscreenFrame`
during the swap-chain teardown/recreate cycle that
`SpectrumWidget::resizeEvent` triggers on widget reparenting
(`floatPanadapter` / `dockPanadapter`). This is an Intel driver bug, but
AetherSDR's pop-out flow reliably triggers it when the process is
running on the Intel GPU.

### Fix

Add the standard NVIDIA Optimus / AMD PowerXpress DLL exports to
`src/main.cpp`. The vendor driver loaders inspect the PE export table at
process startup and bind the discrete GPU instead of the Intel iGPU when
these symbols are present with value `1`.

```cpp
#ifdef Q_OS_WIN
// Request discrete GPU on hybrid laptops (NVIDIA Optimus / AMD PowerXpress).
// Intel iGPU D3D11 driver corrupts its stack during QRhiWidget reparenting (aethersdr#1921).
extern "C" __declspec(dllexport) DWORD NvOptimusEnablement             = 1;
extern "C" __declspec(dllexport) int   AmdPowerXpressRequestHighPerformance = 1;
#endif // Q_OS_WIN
```

**Scope:** the exports are no-ops on Intel-only hardware (no dGPU
present) and are compiled out on macOS and Linux. This is the same
mechanism used by Qt Quick, Chromium, and every major game engine for
this problem.

**Reporter-verified:** reporter confirmed AetherSDR launches on the RTX
4090 and the pop-out crash does not reproduce with this change applied
(see issue aethersdr#1921).

### What this does NOT fix

Intel-only laptops (no discrete GPU) are unaffected. The double
`resetGpuResources()` call pattern in
`PanadapterStack::floatPanadapter()` and `dockPanadapter()` (immediate +
deferred via `refreshAfterReparent()`) is the structural trigger on the
Windows D3D11 path — that is a separate follow-up issue requiring
cross-backend testing.

## Files changed

- `src/main.cpp` — +7 lines (one `#ifdef Q_OS_WIN` block + surrounding
blank lines)

## Test plan

- [ ] Linux build clean (no new warnings — `#ifdef Q_OS_WIN` compiles
out)
- [ ] `check-windows` CI green (MSVC build, no `C4190` or related
warnings)
- [ ] Windows: `dumpbin /EXPORTS AetherSDR.exe | findstr -i
"Optimus\|HighPerf"` shows both exports
- [ ] Windows hybrid-GPU: AetherSDR starts on discrete GPU; pop-out does
not crash

🤖 Implemented with [Claude Code](https://claude.com/claude-code)

…ayDirty() (aethersdr#3338) (aethersdr#3411)

## Problem

The 9 spot-display setters in `SpectrumWidget.h` call `update()`, which
on the GPU path reuses the cached `m_overlayStatic` chrome texture
without re-baking it. `drawSpotMarkers()` never re-runs, so toggling
**Spot Lines** (or changing spot font size, start %, colours, etc.) has
no immediate visual effect — the change only takes hold when something
else triggers `markOverlayDirty()` (e.g. a new incoming spot).

This regression was introduced by aethersdr#3124 (GPU path caches the chrome
overlay) and became consistently visible after aethersdr#3299 (discrete GPU
preference on Windows) caused more users to hit the GPU path.

## Fix

Replace `update()` with `markOverlayDirty()` in all 9 setters.
`markOverlayDirty()` calls `update()` internally — identical behaviour
on the CPU path, correct invalidation on the GPU path.

All other display setters in the file (background opacity, MQTT display,
prop forecast, etc.) already use `markOverlayDirty()`. The spot setters
were the only outliers.

## Testing

Verified build compiles cleanly on macOS. GPU-path visual verification
(toggle Spot Lines with spots visible → lines appear/disappear
immediately) requires Windows with discrete GPU — the reporter in aethersdr#3338
should be able to confirm.

Fixes aethersdr#3338