Reviewed the two PR-specific commits (597ff84c, b4ce5766); the third commit 1c40d965 and its files (panscope.frag, SpectrumWidget.cpp) are the stacked #3975 and out of scope here. CI is green across build/macOS/Windows/CodeQL.

Overall

This is a well-architected fix. The layering is the right call, and the load-bearing layer is the cheapest one: because the radio broadcasts the reassigned client_handle to every connected client, the superseded session's own PanadapterModel::applyPanStatus flips ownedByClient() false and the ownership gate in wirePanadapter silences it — no timers, no eviction round-trip needed. Eviction is correctly positioned as the pre-4.2-firmware backstop. Conventions are respected (AppSettings via ourStationName(), RAII, QStringView/std::clamp), and the fail-open bias in ownedByClient (unknown/unparsable/0 → treated as ours) is the right default — a parse glitch degrades to "send anyway," never to "silently muted forever."

Signal-signature propagation checks out: both RadioConnection/WanConnection emit sites pass msg.handle (populated for S<handle>| status at CommandParser.cpp:77), both connect() calls use member-pointer syntax to the new 3-arg slot, and the public RadioModel::statusReceived relay stays 2-arg so TciServer/MemoryDialog are untouched.

Minor (non-blocking)

• Duplicated hex-handle parsing. The 0x-strip + toUInt(&ok, 16) dance is now open-coded in PanadapterModel::ownedByClient and applyPanStatus. RadioModel already has a parseClientHandle() free helper doing exactly this (RadioModel.cpp:130) — worth a small static equivalent on PanadapterModel so the two copies can't drift (e.g. one treating 0 as "ours" and the other not).

• ForeignPanWrite pan-id parse. noteForeignPanWriteIfAny hand-parses the id with object.mid(12).section(' ', 0, 0) while the main status dispatcher uses the panRe regex. It happens to be correct (and "display panafall " is excluded by the trailing space), but keying off the same regex/normalizePanadapterId path everything else uses would be more robust to future object-format tweaks.

One thing to confirm

The 3-strike foreign-write path force-disconnects another client — outward-facing and hard to reverse. The gate (≥3 writes to a pan we still own and radio-reported program==AetherSDR and matching radio-reported station) is tight, and you've documented that this exact path couldn't be provoked on 4.2.18. The residual risk is two legitimate same-station AetherSDR sessions, but since a pan carries a single client_handle, a foreign write to a pan the radio still says we own is genuinely anomalous — so the classification looks sound. Flagging only because it's the one branch that acts on another session and wasn't hardware-exercised end-to-end.

Nice work on the get clients verb + zombie_session_sim.py harness — turning "minDbm drifts between polls" into an attributable culprit roster is a real diagnostic upgrade. Thanks @jensenpat.

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

Review: request changes

Deep pass over the eviction/ownership work (multi-agent finders + adversarial verify; the SpectrumWidget/panscope hunks are identical to #3975 and were reviewed there, not here). The get clients verb and the foreign-write detection/forensics are genuinely useful and I'd like to see them land. But two of the three defense layers are currently dead code, and the one live layer can force-disconnect a healthy client — so I'm requesting changes on the mechanism, not just lines. Each inline comment carries a fix (apply-able suggestion where clean, a code sketch where the fix is structural).

Dead / non-functional:

1. Reclaim eviction never fires — the guard added in b4ce5766 reads m_staleSessionOwnHandle, which is captured after the new handle lands, making it always-false (RadioModel.cpp:2106 / :3946). This is why the "reclaim eviction: live-proven" note no longer holds.
2. Ownership-transfer tracking never runs — classifyOwnedStatus drops a reclaimed pan's foreign-owner status before applyPanStatus sees it, so ownedByClient(ours) stays true and the Layer-1 gate is a no-op (PanadapterModel.cpp:71).

Unsafe (the one live layer):
3. A healthy second operator can be force-disconnected — the identity gate is station-name-only with no liveness check; two same-hostname operators collide (RadioModel.cpp:4082). Recommend gating the disconnect behind an opt-in (default off) per AGENTS.md, plus a recency window.
4. Fail-open ownership as eviction evidence — writes to a not-yet-attributed pan are tallied as writes to ours (RadioModel.cpp:4050). The eviction tally must fail closed.
5. Eviction state is never reset — recycled FLEX handles then suppress legitimate evictions and mislabel get clients (folded into comment 1).

Minor: get pan emits "0x" for an unset handle; braces-on-control-flow; and three hand-rolled copies of a handle parser that gates a disconnect — reuse the existing helpers.

Threading is clean — mutator (onStatusReceived) and reader (doGet) both run on the main event loop, no race.

Suggested path: land the detection + get clients half; hold the automatic eviction until findings 1-4 are addressed and you've decided (finding 3) whether client eviction should ship at all or stay opt-in. Independent of the rest of the queue, so nothing else is blocked.

Approving — the review-fixes commit (679d4282) addresses all 10 findings from the two passes. Spot-verified the load-bearing ones in the code (not an exhaustive re-review of the +425-line delta): reclaim-eviction guard now captures the pre-reconnect handle at registration (no longer dead code); the foreign-owner Ignore branch stamps the new owner so Layer-1 ownedByClient() actually flips; the 3-strike eviction is gated behind StaleSessionDefense.EvictionEnabled (default OFF — detection/forensics still run); evidence uses the fail-closed ownerHandle(); per-disconnect state reset; and the applyPanStatus dangling-QStringView UB is fixed. The opt-in default-off eviction is the right call given the force-disconnect risk. Nice thorough remediation.