[agessaman]

Problem

The 15 s cross-slot guard keeps two TLS handshakes from overlapping (one handshake needs about 35 KB of internal heap, and boards without PSRAM run with 40-70 KB free). Two paths started handshakes without consulting it:

• JWT renewal bounce. When a token neared expiry on a broker that enforces it, maintainSlotConnection() soft-disconnected and reconnected at once, even if another slot had started a handshake in the same pass or within the guard window. It armed the guard only afterwards.
• Corrected clock. After an NTP correction, syncTimeWithNTP() reconnected or bounced every slot with a stale token in one loop, back to back, and never armed the guard.

Fix

Both paths now take a turn through the guard.

• Renewal. If a bounce is needed while the guard is busy, the slot waits and nothing is touched: no token minted, throttle not stamped, no disconnect. The session keeps publishing. Once the guard is idle it mints, bounces and arms the guard. With the guard idle, a renewal runs in the same pass as before, and a renewal that needs no bounce never waits.
• Corrected clock. The loop still mints and stages credentials but only marks the slot (clock_bounce_owed). Each marked slot is served in maintainSlotConnection(), one per guard window. If its staged token has aged into the renewal buffer by then, it is re-minted first, so there is one handshake with fresh credentials.
• No starvation. A backoff reconnect or breaker probe that is rejected locally (no handshake launched) restores the guard to what it was. While a slot is waiting, other slots' backoff reconnects and breaker probes yield to it.

The decisions are pure functions in MQTTConnectionPolicy.h (renewalStep, owedBounceStep, bounceHandshakeAllowed, owedDispatchNeedsMint). New state is bridge-task only: two bools per slot and one mask byte.

Worst-case wait for a renewal is about 90 s with five slots, against the 300 s renewal lead of every shipped preset. A custom token lifetime of 600 s or less (60 s lead) can expire while waiting; the broker then closes the session and the reconnect goes out with a fresh token.

Unchanged: first setups, reconfigures, link-recovery retries, non-JWT slots, and backoff reconnects and breaker probes when no slot is waiting.

Testing

• 765 native tests pass (15 new in test_mqtt_connection_policy).
• Builds: heltec_v4_repeater_observer_mqtt, Heltec_v3_repeater_observer_mqtt.
• Heltec V4 A/B against observer-firmware-dev, both images with the same scratch hooks (300 s token lifetime for custom slots, clock-back and NTP-sync commands; not in this PR). Slots 2 and 5 pointed at two local mosquitto brokers, slots 1, 3 and 4 left on their presets:

Test	Without the fix	With the fix
Two renewals due in one guard window	bounces 8 s apart	second slot logged token renewal waiting for the handshake guard, kept publishing, bounced 15 s after the first
Clock set back 2 h, then NTP sync	bounces 1 s apart	both logged reconnect queued; bounces 15 s apart, none skipped

All five slots stayed ok on both images and heap was unchanged across the runs.

Not tested: more than two slots colliding, TLS brokers on the renewal path (the local brokers were plain TCP), the yield of other slots' backoff reconnects while a slot waits, a staged token aging before its turn, V3, Station G3 and Ethernet boards. The host tests simulate the bridge's order of operations; they do not run MQTTBridge.cpp.

This and #98 both change the backoff-reconnect block in MQTTBridge.cpp; the second to merge needs a conflict resolved.