Thanks for a careful, well-documented fix, @K5PTB — the comments explaining why each branch behaves the way it does made this easy to review. The core design (dialectSupportsVfoB() as a single capability rule, display-only override, lossless dialect round-trip) is sound, and CI is green across build/macOS/Windows/CodeQL.

I verified the parts that aren't obvious from the diff alone:

• CatPopoutWindow.{cpp,h} deletion is safe. No references anywhere outside the two deleted files, and it isn't in CMakeLists.txt (the source list is explicit, not a glob), so it was genuinely dead. Good cleanup.
• Load-time graying works. buildTableRows() calls updateRowLocked() per row (CatControlApplet.cpp:485), so a port already saved as rigctld comes up with VFO B forced to "—" and disabled — not just after a dialect toggle.
• setMaxSlices() restore-by-data preserves the disabled state for rigctld rows, since it restores from the combo's current data ("—") rather than re-reading settings.
• MainWindow scope is clean. The three-dot PR diff only touches the migration default (CatPort_0_VfoB → -1); the locale-date hunk that shows up in a two-dot diff is just a stale-branch artifact (branched at 23ef4556, before #3511 merged) and won't revert that feature on merge.

Two small observations, neither blocking:

1. persistVfo() ambiguity for VFO A. When a saved-but-unavailable slice exists (smaller radio) and the combo has fallen back to the fallback entry, a user deliberately selecting that fallback slice (e.g. genuinely picking slice A) is indistinguishable from the fallback and gets ignored in favor of the preserved value. This is the documented, intended trade-off and the right default — just noting it's a real (if rare) corner where a deliberate pick won't stick until the slices return.

2. Pre-existing migrated users keep CatPort_0_VfoB="1". The migration is guarded by !contains("CatPort_0_Port"), so anyone who already migrated under the old seed retains the stored 1 for the rigctld port. It's harmless (rigctld ignores it, and applyRowToSettings no longer persists it), and it would resurface as slice B only if they later switch that port to a dual-VFO dialect — arguably reasonable. Worth a mention only so it's a known behavior, not a surprise.

Nice work, and the issue write-up in #3694 made the intent very clear. 👍

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

Thorough review complete — approving.

Verified independently (not just from the diff):

• Satisfies #3694 fully — all three acceptance criteria: rigctld VFO B forced to "—" and disabled (load-time via updateRowLocked at build, not just on toggle); saved VFO B preserved across a dialect switch and restored on switch-back; migration no longer seeds a VFO B for the default rigctld port.
• CatPort::kVfoNone reuse replaces magic -1 literals (constant pre-existed) — clean.
• CatPopoutWindow deletion is safe — every reference lived inside the two deleted files, and it was not in CMakeLists.txt (explicit source list), so it was never compiled.
• MainWindow scope is clean — three-dot diff touches only the migration default; no #3511 locale-date revert on merge.
• Restore-by-data (VFO A and B, in load + setMaxSlices) fixes a latent index/qMin repointing bug; runtime wiring (CatPort.cpp/RigctlProtocol.cpp) is untouched, so VFO B stays functional where consumed.

On @jensenpat's hold (well-raised): the persistence change does reach the shared path, but its behavioral delta is confined to the smaller-radio-reconnect corner — when a saved slice is unrepresentable, persistVfo preserves it instead of clobbering; for any representable selection on a same-size radio it is byte-for-byte identical to the prior setValue, so the dual-VFO/SmartCAT common path is unchanged. The one documented limitation (a deliberate re-pick of the fallback entry in that corner won't stick until the slices return) is an accepted trade-off.

Decision to land now rather than hold: our release velocity makes a long-lived parallel branch drift too far from main to test meaningfully — holding it would add integration risk rather than reduce it. Scope captured accurately in the squash subject per @jensenpat's point.

Thanks @K5PTB — the per-branch "why" comments made this easy to verify, and the #3694 write-up was excellent.