What happened?

The number of CAT ports a user can run is silently capped to the connected radio's maximum slice-receiver count — the model's hardware capacity (e.g. 4 on a FLEX‑6500, 8 on a 6700), not the number of currently-open slices.

In MainWindow::applyCatPortCount(), a port's shouldRun is gated on (i < target), where target is catPortTargetCount() → RadioModel::maxSlicesForModel(). So on a 4‑receiver radio you can never run more than 4 CAT ports: a 5th+ enabled port never starts, even with a valid TCP port and no slice involvement, and there is no error or UI feedback.

This is a vestige of the old "one CAT port = one slice" assumption (from before the multi-port CAT config). The two aren't coupled: multiple CAT clients can legitimately share a slice, and a port mapped to a not-yet-present slice already degrades gracefully ("Slice Not Present"). The receiver capacity should only bound the VFO-letter choices (which setMaxSlices() already handles), not how many ports run.

What did you expect?

Any enabled CAT port with a valid port number (≥1024), up to the configured maximum, should start regardless of the radio's slice-receiver capacity.

Steps to reproduce

1. Connect to a radio whose model supports N slice receivers (e.g. FLEX‑6500 → 4).
2. Open CAT config; enable a CAT port at row index ≥ N (e.g. a 5th port) with a valid TCP port (≥1024).
3. Observe the port never starts / never accepts connections.

Radio model & firmware

FLEX‑6500 (logic is platform- and model-independent)

Operating system

macOS / Linux / Windows (the gate is in shared GUI code)