Thanks @jensenpat — this is a clean, well-reasoned change. I checked the 3D tick mapping against the actual render path and it lines up.

What I verified

• yForDbm() matches the surface geometry exactly. The front row in dss_mesh.vert (v=0) maps baseY = 1.0 → specRect.bottom(), and ridge = pow(sLin, max(zCurve,0.05)) * frontMaxRidgeFrac → topY = 1.0 - ridge. The overlay's specRect.bottom() - strength^zc * height*kFrontMaxRidgeFrac reproduces that term for term, including the std::max(0.05, m_dssZCurve) clamp that mirrors the shader's max(zCurve, 0.05). Since the GPU mesh viewport (renderGpuFrame) and the CPU fallback quad are both stretched to specRect, plot-space [0,1] maps to specRect in both paths, so the scale tracks the drawn ridge in either renderer. Good call scoping the scale to the front (live) trace — receding rows shrink by w and raise their baseline, so a single amplitude axis is only honest for v=0, and the PR text says exactly that.
• Chrome factoring is faithful. drawDbmScaleChrome() is the unchanged strip background / border / ▲▼ block, and 2D drawDbmScale() calls it then runs the original label loop verbatim — 2D is byte-identical as claimed, and the strip geometry (hence the existing drag/arrow/wheel ref-level hit targets at DBM_STRIP_W / DBM_ARROW_H) is preserved in 3D.
• Defensive ordering is right: chrome is drawn before the rangeDb <= 0.0f early-return, so even a degenerate span still paints the strip and keeps click targets live. (dssSpanDb() clamps to [45,120] so that guard is effectively dead, but harmless.)

No convention, lifetime, or resource concerns — no QSettings, no raw pointers dereferenced, and the change is confined to the two files in scope.

One minor note (not blocking)

The scale reads rangeDb = dssSpanDb() unrounded, but the surface (both renderGpuFrame UBO at line ~8663 and buildDssImage at line ~7554) renders from std::round(dssSpanDb() * 2.0f) / 2.0f — quantized to 0.5 dB. floorDbm is already quantized inside dssFloorDbm(), so only the span differs, by ≤0.25 dB. That's ~1–2 px of tick drift near Ref (less lower down thanks to the pow compression), so visually a non-issue — but since the PR body emphasizes the scale using "the exact values the mesh renders from," rounding rangeDb the same way here would make that literally true and immune to any future span-quantization change.

Nice work — the shader-accurate mapping and the shared-chrome approach are the right way to do this.

_{🤖 aethersdr-agent · cost: $3.0507 · model: claude-opus-4-8}

High-effort review (8 finder angles + verification). The 3D dBm scale mostly works, but there are two spots where the scale can disagree with the surface (inline). Summary:

• Scale lags the live noise-floor drift (concrete, fixable): the surface tracks the measured floor per-frame via the UBO, but this scale overlay only redraws on markOverlayDirty(), which the noise-floor update path never calls — so on a static pan the surface visibly shifts while the labels stay put (up to 0.5 dB).
• Linear axis vs. z-curved surface (design call): ticks are placed linearly while surface height is pow(sLin, zCurve), so mid-scale ticks don't line up with the ridges. It's documented as a 'full-height reference' — worth deciding whether to honor the z-curve for the front row or reframe the axis.
• Minor: round the scale's span to match the mesh (suggestion inline); the new floor-drag gesture is mouse-only (mitigated by the keyboard-reachable '3D Floor' slider).

Verified non-issues so you don't chase them: setDssFloorDepth does clamp [0,24] and has a change-guard (no per-mousemove full rebuild); the FP-loop / double-draw / tooltip-race concerns don't hold on the single GUI thread. Requesting changes mainly for the floor-drift lag plus a decision on the linear axis — the rest is polish.

Re-review — all four findings resolved.

Fixed in 2f5ac35:

• Scale lagged the live noise-floor drift → the quantised 3D floor is now tracked in renderGpuFrame's display-state change detector, so a floor change marks the overlay dirty and the scale redraws in lock-step with the surface (3D-only; 2D stays Ref-anchored).
• Span rounding mismatch → drawDbmScale3D now rounds the span std::round(span*2)/2 to match buildDssImage / renderGpuFrame, so labels and ridges agree to the pixel.

Accepted as-is (maintainer decision):

• Linear vs. z-curved axis → keep the linear full-height amplitude reference. On a perspective/curved surface no axis can be truly pixel-accurate, and the front-ridge-aligned alternative would compress ticks into the lower ~46% of the strip. Documented behavior stands.
• Floor-drag a11y → the keyboard-accessible "3D Floor" slider already drives the same setting, so the mouse-only strip gesture is an accepted convenience.

Build/macOS/Windows green. Clearing the earlier changes-requested.