…nabled check (#3201)

## Summary

Closes a gap in the adaptive frame-rate throttle toggle introduced in
#3175.

When a panadapter was **opened mid-session** while the network was
already in a degraded state, `ensureOwnedPanadapter()` applied the
active fps cap directly via `sendAdaptiveCapToPan()` without consulting
`AdaptiveThrottleEnabled`. The toggle was bypassed for newly-registered
pans, including the deferred `waterfallIdChanged` re-apply lambda.

## Approach: gate at the source

Rather than adding inline checks at each call site (which multiplies the
guard and creates a latent risk for future callers), the fix moves the
enable check into `currentAdaptiveFpsCap()`:

```cpp
int RadioModel::currentAdaptiveFpsCap() const
{
    if (AppSettings::instance().value("AdaptiveThrottleEnabled", "False").toString() != "True")
        return 0;
    return fpsCapForState(m_netState);
}
```

`ensureOwnedPanadapter()` already gates on `activeCap > 0` — it gets
correct behaviour for free with no other changes.
`applyAdaptiveFrameRate()` keeps its own early-return as a short-circuit
(it calls `fpsCapForState` directly, not `currentAdaptiveFpsCap`).

## All `sendAdaptiveCapToPan` call sites now covered

| Location | How gated |
|---|---|
| `applyAdaptiveFrameRate()` | explicit early-return (short-circuit;
calls `fpsCapForState` directly) |
| `ensureOwnedPanadapter()` immediate cap | `activeCap > 0` —
`currentAdaptiveFpsCap()` returns 0 when off |
| `ensureOwnedPanadapter()` `waterfallIdChanged` lambda | same — `cap >
0` check calls `currentAdaptiveFpsCap()` |

## Additional nits addressed

- `Qt::UniqueConnection` added to the `waterfallIdChanged` lambda to
prevent duplicate cap commands if `waterfallId` changes more than once
on a pan
- Comment added documenting the narrow ordering edge case: pan created
healthy → network degrades → `waterfallId` arrives before next tier
transition. `applyAdaptiveFrameRate()` catches it on the next
transition; noted, not fixed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

…hersdr#3175)

## Summary

- Adds an **\"Enable adaptive frame-rate throttle\"** checkbox to all
three connection modes, wired to a new `AdaptiveThrottleEnabled`
AppSettings key (default `False` — opt-in)
- **Live-reads** `AppSettings` inside `applyAdaptiveFrameRate()` on
every quality state transition instead of caching at connect time —
toggle is responsive mid-session, not just at next connect
- Tooltip is explicit: toggling mid-session takes effect at the next
quality update; reconnect lifts an already-applied cap immediately
- Fixes aethersdr#3173 (user seeing automatic fps reduction they didn't expect —
caused by aethersdr#2829 shipping always-on)

## Design decisions addressed from review

| Concern | Resolution |
|---|---|
| Cached flag ignored mid-session toggles | Dropped
`m_adaptiveThrottleEnabled` member; `applyAdaptiveFrameRate()` reads
AppSettings live |
| Tooltip implied a live switch | Updated to explain next-quality-update
semantics and reconnect-to-lift |
| Default `True` vs `False` | Keeping `False` (opt-in) — issue aethersdr#3173
confirms the always-on behaviour surprises users |

## All three connect paths covered

All paths funnel through `onConnected()` → `startNetworkMonitor()` →
`evaluateNetworkQuality()` → `applyAdaptiveFrameRate()`, so the live
check is reached regardless of connection type.

## Test plan

- [ ] Checkbox appears in all three connection modes, unchecked by
default
- [ ] Check the box, connect; confirm adaptive fps commands appear in
`lcProtocol` as quality degrades
- [ ] Leave unchecked, connect; confirm no fps throttle commands are
sent
- [ ] Toggle mid-session; confirm change takes effect at next quality
state transition
- [ ] Setting persists across app restart

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

…nabled check (aethersdr#3201)

## Summary

Closes a gap in the adaptive frame-rate throttle toggle introduced in
aethersdr#3175.

When a panadapter was **opened mid-session** while the network was
already in a degraded state, `ensureOwnedPanadapter()` applied the
active fps cap directly via `sendAdaptiveCapToPan()` without consulting
`AdaptiveThrottleEnabled`. The toggle was bypassed for newly-registered
pans, including the deferred `waterfallIdChanged` re-apply lambda.

## Approach: gate at the source

Rather than adding inline checks at each call site (which multiplies the
guard and creates a latent risk for future callers), the fix moves the
enable check into `currentAdaptiveFpsCap()`:

```cpp
int RadioModel::currentAdaptiveFpsCap() const
{
    if (AppSettings::instance().value("AdaptiveThrottleEnabled", "False").toString() != "True")
        return 0;
    return fpsCapForState(m_netState);
}
```

`ensureOwnedPanadapter()` already gates on `activeCap > 0` — it gets
correct behaviour for free with no other changes.
`applyAdaptiveFrameRate()` keeps its own early-return as a short-circuit
(it calls `fpsCapForState` directly, not `currentAdaptiveFpsCap`).

## All `sendAdaptiveCapToPan` call sites now covered

| Location | How gated |
|---|---|
| `applyAdaptiveFrameRate()` | explicit early-return (short-circuit;
calls `fpsCapForState` directly) |
| `ensureOwnedPanadapter()` immediate cap | `activeCap > 0` —
`currentAdaptiveFpsCap()` returns 0 when off |
| `ensureOwnedPanadapter()` `waterfallIdChanged` lambda | same — `cap >
0` check calls `currentAdaptiveFpsCap()` |

## Additional nits addressed

- `Qt::UniqueConnection` added to the `waterfallIdChanged` lambda to
prevent duplicate cap commands if `waterfallId` changes more than once
on a pan
- Comment added documenting the narrow ordering edge case: pan created
healthy → network degrades → `waterfallId` arrives before next tier
transition. `applyAdaptiveFrameRate()` catches it on the next
transition; noted, not fixed.

🤖 Generated with [Claude Code](https://claude.com/claude-code)