Thanks for the exceptionally thorough root-cause writeup, @jensenpat — the two-cause regression chain (unconditional smoothing from #3836, infinite-line stroke distance from #3958) is well isolated, and the 4-way same-band capture is exactly the right evidence. All six CI checks are green. The core of the fix is sound: replacing the dFdx-derived infinite-line distance with true endpoint-clamped distance to the adjacent polyline segments is the correct fix for the full-height needles, and gating the binomial blend on the measured plateau fraction is a clean way to preserve the zoomed-in stair-step melt without defocusing wide spans. A few notes, none blocking:

1. Shader: stroke polyline uses a different horizontal column convention than the fill (panscope.frag). The unchanged t/yTrace sampling at line 68 places column i at v_uv.x = i/(N-1) (endpoints inclusive: column 0 at x=0, column N-1 at x=wPx). The new stroke code places column i at (i+0.5)*colW = (i+0.5)/N. These two conventions disagree by up to half a column (~0.5 device px at one-column-per-pixel), sign-flipping across the width and zero-crossing near center. So the stroke is horizontally registered slightly off from the fill it sits on, and the offset varies across the panadapter. It's sub-pixel and both layers are AA'd, so likely imperceptible — but since it's a genuine internal inconsistency, consider deriving the polyline x-positions from the same mapping the fill/color already use (i/(N-1)) so stroke and fill share one registration. The implicit-LOD texture() calls inside the if (coreHalf > 0.0) block are fine, since stroke.x is uniform → the branch is uniform control flow.

2. Stale header comment. The file header (lines 3, 13–15) still describes an "R32F column texture" and "slope-corrected stroke width via screen-space derivatives." Both are now inaccurate after this PR (R16F unconditional; slope correction removed). Worth a one-line refresh so the next reader isn't misled.

3. Plateau threshold is a unit-dependent magic number (SpectrumWidget.cpp). std::abs(bins[i] - bins[i-1]) < 0.01f — since displaySpectrumBins() is in dBm, RBW plateaus are exact repeats (diff ≈ 0), so 0.01 dB catches them robustly and busy noise bins rarely fall under it; the logic is correct. But the 0.01f threshold and the 0.35f/0.30f ramp are unnamed constants sitting next to the already-named kFftDisplaySpatialSmoothBlend. Promoting them to named k… constants (with the dBm-units note) would make the gate easier to tune later. The srcCount < 2 early-return upstream makes the srcCount - 1 divisor safe.

Minor: forcing m_fftColFormat = R16F unconditionally leaves the if (m_fftColFormat == QRhiTexture::R32F) upload branch (~line 9059) as dead-but-harmless code — fine to leave, just noting it. The R16F rationale (filterable everywhere; half precision ample for normalized 0..1) is well-justified and matches #3968.

Nice work — the fix is correct and the perf claim (plateau gate skipping the smoothing copy on wide spans) is consistent with the COW displayBins = bins fast path.

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

Excellent root-causing — the four-way same-band capture and the two-releases/two-causes breakdown make this very easy to review. The plateau-gated smoothing and the true endpoint-clamped stroke distance are both well-reasoned, and the failure mode of the old dFdx-slope approximation (distance to the infinite line → full-height needles on steep flanks) is clearly the right diagnosis. CI is green across all six checks.

One substantive question before this lands, plus a couple of minor notes.

1. Column-center convention mismatch between the stroke and the fill (panscope.frag).

The fill path and the yTrace used everywhere else sample columns with an endpoint convention:

float texX = (v_uv.x * (plot.z - 1.0) + 0.5) / plot.z;   // column i → device-x = i/(nCols-1) * wPx

i.e. the trace spans the full width with sample 0 at the left edge and sample n-1 at the right edge (matching buildFftDisplayTrace producing one point per device column across specRect.width()).

The new stroke reconstruction uses a pixel-center convention instead:

float colW = plot.x / nCols;
pt[k] = vec2((ci + 0.5) * colW, (1.0 - ty) * hPx);       // column i → device-x = (i+0.5)/nCols * wPx

These two mappings disagree by up to ~½ a column width (largest at the left/right edges, crossing zero mid-plot). At typical column counts colW ≈ 1 device px so the offset is sub-pixel — but the whole point of this PR is pixel-crisp stroke/fill registration, and on a steep peak flank a ~0.5 px horizontal shift of the stroke polyline relative to the fill's top edge is exactly the "stroke floating off the trace" class of artifact. Could you confirm this is intended, or align the stroke to the same endpoint mapping the fill uses, e.g.:

float denom = max(nCols - 1.0, 1.0);
pt[k] = vec2(ci / denom * plot.x, (1.0 - ty) * hPx);

and sample columns at the matching (ci + 0.5)/nCols texel center (or texelFetch) so the reconstructed polyline is bit-identical to what the fill/yTrace path sees. On Retina (2×) the current offset is half the logical size, which is likely why it looked clean in the parity grabs but might not be at 1× DPI — the same DPI asymmetry this PR is calling out for the old spikes.

2. R16F-unconditional — reasonable, but two stale references. Folding in #3968 is fine and the half-precision argument holds for normalized 0..1 amplitude (worst-case ~0.5 px quantization near the top of the range). Two doc leftovers: the shader header still says "width×1 R32F column texture" (line 3) and describes "slope-corrected stroke width via screen-space derivatives" (lines 13–14), both now superseded by this change. The renderGpuFrame upload still branches on m_fftColFormat == QRhiTexture::R32F, which is now dead (the R32F arm can never be taken) — harmless, but worth collapsing to just the R16F path for clarity since the format is no longer conditional.

3. Scope. Bundling the #3968 R16F hardening into a #3967/#3932 trace-crispness fix is defensible given you touch the same pipeline, and you documented why #3968 couldn't have caused the reported bug — no objection, just flagging it's technically a third issue riding along.

Nothing here blocks the approach; the smoothing gate and stroke-distance rewrite are solid. Mainly want the column-center conventions unified (or a note confirming the sub-pixel offset is deliberate) before merge. Thanks for the thorough writeup and the hardware validation.

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

Traced the two-cause regression chain independently: infinite-line stroke distance (steep-flank spikes, #3967) and unconditional smoothing blend (wide-span defocus, #3932) are both correctly diagnosed and fixed. Plateau fraction gate is well-structured; endpoint-clamped polyline distance matches old geometry-quad coverage; R16F consolidation is sound. Hardware-validated on FLEX-8400M with 4-way same-band comparison (Principle XI). CI 6/6 green. Tier 3 only — merging.