NAC mismatch detection, false sync suppression, SPS hunt stabilization

[bdwyertech]

Three fixes for P25 trunked scanning stability, identified from debug logs on a Motorola P25 Phase 1 system with RTL-SDR R828D tuner.

1. NAC mismatch detection in trunk state machine
Files: p25_trunk_sm.c, p25_trunk_sm.h

When the decoder lands on a wrong frequency (e.g., adjacent traffic channel after a mis-tune), it sees a different NAC but the state machine only detects cc-lost via timestamp staleness after the full cc_grace window (5 seconds). During that time, every frame is duid:EE with frequent NID parity mismatches.

Added a nac_mismatch_count field to p25_sm_ctx_t and a check in the ON_CC tick handler that compares state->nac against state->p2_cc (the expected CC NAC from Network Status Broadcast). After 3 consecutive mismatches, triggers cc-lost-nac-mismatch and immediately hunts for the correct CC. Transient NAC values 0 and 0xFFF (which appear during signal drops) are ignored.

Reduces wrong-NAC dwell from ~7 seconds to under 1 second.

2. False D-STAR/YSF sync suppression when locked to P25
File: dsd_frame_sync.c

On noisy P25 frames, the 20-symbol YSF and 24-symbol D-STAR sync patterns occasionally match by chance, causing a brief false protocol switch that disrupts P25 decoding. Observed as Sync: +DSTAR VOICE and Sync: +YSF with garbage data in debug logs while actively tracking a P25 control channel.

Added !DSD_SYNC_IS_P25(state->lastsynctype) guards to both the YSF and D-STAR sync detection blocks. When the decoder is currently tracking a P25 signal, it skips YSF and D-STAR pattern matching entirely.

3. SPS hunt cycle stabilization
File: dsd_frame_sync.c

The multi-rate SPS hunting cycled every 3 buffer passes (~0.5 seconds), causing rapid oscillation between 4800 and 6000 sym/s on secondary control channels with marginal signal. This produced repeated ON_CC → HUNT → ON_CC cycles at startup (6+ cycles in 17 seconds observed).

Increased the cycle interval from 3 to 5 buffer passes (~0.8 seconds) to give each symbol rate more time to acquire sync before switching.

Testing
All three fixes validated on live air against the same Motorola P25 Phase 1 trunked system. Compared debug logs before and after across multiple sessions (~20 minutes total):

NAC mismatch episodes: eliminated (0 occurrences vs 1 sustained 7-second episode)
False D-STAR/YSF syncs: eliminated (0 vs 2 in previous logs)
SPS hunt cycles at startup: eliminated (1 normal cc-lost/hunt vs 6+ rapid oscillations)
Voice call grant/tune/decode/release cycle: working correctly throughout
No regressions in TSBK decoding, frequency mapping, or adjacent site tracking

[arancormonk]

@bdwyertech Thanks for the contribution and for digging into the CC reacquisition issue.

I pushed a maintainer follow-up commit to this PR. I kept the intent of your fix, but tightened the behavior in a few places:

• The P25 trunk state machine now latches the expected control-channel NAC, so decoded P1 NID updates cannot overwrite the comparison target before mismatch handling runs.
• YSF/D-STAR sync suppression is now limited to active P25 trunking lock, instead of suppressing those protocols any time the previous sync was P25.
• The longer SPS hunt dwell is now scoped to P25 trunk control-channel hunting, so other auto-detect modes keep the previous dwell behavior.
• I added regression coverage for the NAC mismatch path and the new frame-sync policy helpers.

Could you test the updated branch against the setup or capture that showed the original issue and confirm it still solves the problem on your end?

[bdwyertech]

Yep, looks good -- I will give it a shot, thanks!