…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

…U path (#3606) (#3713)

## Summary

Fixes #3606. In the GPU (`QRhi`) render path the panadapter **grid**
(the dB / frequency lines that form the rectangular cells) was
composited **on top of** the FFT trace, so it painted over the signal
peaks — visible interference in the reporter's screenshot. This moves
the grid below the trace, matching the software path and conventional
panadapter rendering.

## Root cause — GPU vs. software z-order parity gap

The software (`QPainter`) path already draws the grid correctly,
**behind** the trace:

```cpp
drawGrid(p, specRect);      // grid first
drawSpectrum(p, specRect);  // trace on top
```

The GPU path composites the frame from texture layers. Per
`renderGpuFrame()` the order is (bottom → top):

1. waterfall
2. **background layer** `m_overlayBg` (fill + background image) —
explicitly drawn *below* the FFT (this is what #3124 fixed for the
background image)
3. FFT fill + line (the trace / peaks)
4. **static overlay** `m_overlayStatic` — drawn *above* the FFT
5. slice flags

The grid was baked into the **static overlay** (step 4), so it
composited *after* — i.e. over — the peaks. #3124 moved the background
*image* below the trace but left the grid on top; this closes the
remaining half of that parity gap.

> The maintainer triage bot independently reached the same diagnosis and
proposed this exact move — see the [triage comment on
#3606](#3606).

## The change

Move **only** the grid into `m_overlayBg` (the layer already composited
below the FFT). Everything else in the static overlay — band plan,
slice/TNF markers, frequency scale, indicators — stays on top, exactly
as the software path draws them after `drawSpectrum()`.

Resulting GPU order, now identical to software:

```
waterfall → bg fill/image → grid → FFT fill/line → band plan / markers / scales / flags
```

## Performance — neutral by construction

The grid is in the render hot path, so worth being explicit: this is
**zero-cost**. `m_overlayBg` and `m_overlayStatic` are both rebuilt
under the *same* `m_overlayStaticDirty` gate and uploaded on the same
cadence. The grid was already painted once per dirty event; it is now
painted into a different cached layer — same paint, same upload, no
per-frame work added. No interaction with the waterfall or FFT
pipelines.

## Constitution principle honored

**Principle XI — Fixes Are Demonstrated.** Verified visually: grid
renders behind the peaks (before/after screenshots below). The software
path is the reference for correct z-order.

<!-- before: grid painting over the peaks (current release) -->
<!-- after:  grid sitting behind the peaks -->

## Test plan

- [x] Local build passes (Windows, Qt 6.8.3 msvc2022_64, GPU path on)
- [x] Visual check: grid now composites behind the FFT trace, matching
the software path
- [ ] Existing tests pass (CI)
- [x] Reproduction / expected result documented (#3606)
- [ ] Cross-platform GPU paths (Metal/Vulkan) — same code path; a
macOS/Linux screenshot welcome

## Checklist

- [x] Commits are signed (SSH)
- [x] No new flat-key `AppSettings` calls (N/A)
- [x] Code is clean-room (Principle IV)
- [x] All meter UI uses `MeterSmoother` (N/A)
- [x] Documentation updated if user-visible behavior changed (N/A — code
comments at the move sites)
- [x] Security-sensitive changes reference a GHSA if applicable (N/A)

---------

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>

…age (aethersdr#3124)

## Summary

Pre-fix the two spectrum paint paths disagreed on z-order for the
user-set background image vs the FFT trace:

| Path | Z-order (bottom → top) |
|---|---|
| Software fallback | bg image → grid → **FFT** → band plan → markers |
| GPU (QRhi) | waterfall → **FFT** → static overlay (bg + grid + band
plan + markers) |

Result: in GPU mode the bg image painted **on top of** the FFT trace,
tinting and occluding it. Software mode rendered the FFT correctly on
top of the bg image.

This PR splits the GPU static overlay into **two textures** so the bg
image can render BELOW the FFT while the chrome (grid, band plan,
scales, markers) stays above. Render order is now:

\`\`\`
Clear → Waterfall → BG quad → FFT fill+line → Chrome overlay quad
\`\`\`

## What changed

### \`src/gui/SpectrumWidget.h\`
- \`m_overlayBg\` QImage — bg image alone, parallel to
\`m_overlayStatic\`
- \`m_bgGpuTex\` QRhiTexture — uploaded copy of \`m_overlayBg\`
- \`m_bgSrb\` QRhiShaderResourceBindings — points at \`m_bgGpuTex\` via
the shared \`m_ovSampler\`
- \`m_overlayBgNeedsUpload\` bool — drives the upload step

### \`src/gui/SpectrumWidget.cpp\`
- \`initOverlayPipeline()\`: parallel scaffolding for the bg texture +
SRB. **Reuses** \`m_ovPipeline\`, \`m_ovVbo\`, \`m_ovSampler\` — same
alpha-blending shader, same quad geometry, same linear sampler. Only the
SRB switches between draws so the same overlay pipeline paints two
different textures.
- Resize path: bg texture follows \`m_overlayStatic\`'s pixel size.
- Static-overlay paint: bg image painting moved out into its own \`if
(m_overlayStaticDirty)\` block that draws only into \`m_overlayBg\`. The
original block still composes grid + band plan + scales + markers into
\`m_overlayStatic\`, just without the bg image step.
- Upload step: \`m_overlayBg\` uploaded to \`m_bgGpuTex\` alongside the
existing \`m_overlayStatic\` upload (same upload batch).
- Render order: new bg-quad render block inserted between the waterfall
pass and the FFT fill/line pass.

## Compositing math preserved

Both paths still use the same \`(1.0 - m_bgOpacity / 100.0)\` opacity
curve for the bg image — software path overlays a dark tint at
\`m_bgOpacity * 255 / 100\` alpha on top of a full-opacity bg; GPU path
draws the bg image directly with reduced opacity against the dark clear
colour. Visual result is equivalent at the endpoints and follows the
same linear interpolation between them, just with the bg image now
sitting *below* the FFT.

## Software path unchanged

The software fallback (\`#else !AETHER_GPU_SPECTRUM\`) already rendered
FFT above bg. No edits there.

## Build verified clean

- [x] AetherSDR builds clean on Linux x86_64 GPU path
- [x] All 320 targets including every test target build without errors

## What's still inconsistent (out of scope)

Grid lines and band-plan stripes are also drawn into the static overlay
in GPU mode, so they currently sit *above* the FFT trace where software
mode draws them *below*. Visually mild (grid lines are thin), and out of
scope for the bg-vs-FFT fix Jeremy asked for. If the grid z-order
becomes a real annoyance, the same split-into-pre/post-FFT-overlays
pattern extends to a third texture for grid + band plan.

## Test plan

- [ ] CI: build / check-paths / check-windows / CodeQL
- [ ] Visual smoke: set a background image with Choose…, drag the BG
Opacity slider — confirm the FFT trace remains crisply visible on top of
the image at all opacity values, on both GPU and software paths (toggle
via \`AETHER_NO_GPU=1\` env var)

73, Jeremy KK7GWY & Claude (AI dev partner)

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

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…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