Summary

Root cause of #3951 ("spectrum line jumping up & down every ~1–1.5 s, waterfall fine, since 26.6.x"), established from the reporter's support bundle. This is a session-model bug, not a rendering bug — it is not covered by the #3967/#3932 trace fix (PR #3975).

Evidence (from the #3951 support bundle)

• The reporter's live session is handle 0x443A5D3C (prior launches: 0x5C8F464B and at least one earlier). It sends zero display pan set … min_dbm/max_dbm commands.
• The radio nevertheless broadcasts ~250 S42FFE1C4|display pan 0x40000000 min_dbm=… max_dbm=… statuses over the log window — min_dbm/max_dbm ratcheting in 0.1 dB steps at ~0.3–1.5 s cadence with the span pinned at exactly 90 dB. That stepping signature is AetherSDR's client-side auto-floor tracker (NoiseFloorEnable=True, position 95 in the reporter's settings.xml).
• Handle 0x42FFE1C4 belongs to none of the logged sessions: it is an earlier, still-alive AetherSDR instance whose auto-floor loop is still running against the pan streamId it remembers.

The three holes that line up

1. MultiFlex doesn't enforce pan ownership on display pan set — any connected client can adjust another client's pan attributes, and the reconnect reclaim path (PR [codex] Fix panadapter restore across reconnects #3429) hands the old session's pan streamId to the new session, so the stale instance's adjustments land on the pan the new session is displaying.
2. The stale session's auto-floor keeps running after it loses the pan — nothing stops the tracker when its pan is reclaimed away or its session is superseded.
3. Foreign-handle dBm-range echoes are applied raw — the client's dBm-range echo smoothing (m_pendingDbmRangeEcho, Fix spectrum dBm range echo smoothing #2793) only suppresses changes this client initiated, so every foreign 0.1 dB step re-scales the trace immediately → the visible ~1–2 px hop. The waterfall absorbs 0.1 dB in its color map, which is why only the trace jumps.

Proposed fix (three layers, roughly independent)

1. Display hardening — apply dBm-range statuses that this client did not initiate through the same smoothing/animation as drag-release echoes. Fixes the visible symptom regardless of who is fighting us (including a SmartSDR client legitimately sharing the pan).
2. Auto-floor discipline — stop the tracker when its session no longer owns the pan (reclaimed away / superseded), so a stale instance stops pushing at all.
3. Reclaim eviction — on reconnect-reclaim, consider issuing client disconnect for our own predecessor handle (SmartSDR does this on takeover), which kills this whole class of two-sessions-one-pan fights.

Repro recipe

Two AetherSDR instances on one pan (bridge station support makes this scriptable): enable Floor=Auto in instance A, have instance B reconnect/reclaim the pan, observe A's S<handleA>|display pan … min_dbm=… statuses bouncing B's trace.

Refs: #3951 (user report), #3429 (reclaim design), #2793 (own-echo smoothing), #2653 (auto-floor tracker).

💻 Filed from the #3967/#3951 root-cause investigation (Claude Code, claude-fable-5) with architecture by @jensenpat