fix(mqtt): stop bouncing a live waev session to renew its token

waev's operator confirmed on 2026-08-11 that their servers do not disconnect a
client when its JWT passes exp — a 60-minute token can hold a session open for
hours. The renewal path assumed the opposite, in as many words: the comment at
the bounce called the renewal buffer "the ONLY margin between 'device
re-authenticates' and 'broker enforces exp and FIN-closes the session
mid-stream' — observed on the waev preset".

That premise made waev expensive, because waev is the only preset with a short
token_lifetime (3300 s; every other is 0, meaning the 24 h default). It was
therefore the only slot bouncing often: measured every ~47 minutes, about 30
times a day per device. And the bounce's re-handshake is where contiguous
internal DRAM goes — one renewal traced on hardware took the largest free block
from 27,124 to 16,372 B, below the 16,384 B mbedTLS inbound record buffer, after
which that slot could not re-handshake at all. The teardown and the credential
update cost nothing; the handshake costs everything.

So for a broker that leaves live sessions alone, refresh the credentials in place
and let the next genuine reconnect use them. That path already existed for the
"token renewed but old one still valid" case; this just stops treating imminent
expiry as a reason to tear down a healthy connection.

mqttPresetEnforcesTokenExp() defaults to true and is keyed by preset name rather
than a new struct field: adding a field would mean re-ordering a dozen positional
initialisers, where a mistake is silent, and the wrong default costs an outage
rather than a re-handshake. Custom and audience-only slots have no preset and are
treated as enforcing.

Our own logs already argued against the premise and we had not noticed: across 14
multi-device outages (10 hitting all four devices) the drops landed within ~3 s of
each other, on devices whose independent boot times gave them independent token
issue times. Independent expiries cannot align that tightly, so exp enforcement
was never a good explanation for them.

Unverified on hardware yet — the operator's statement is second-hand. Next: apply
to one board only and confirm the session survives past exp, that a later
reconnect still authenticates, and that the ~47-minute 27,124<->16,372
oscillation stops.

(cherry picked from commit 27bd05a17b9303b158feec7dab60af2fe128f5ce)

src/helpers/MQTTPresets.h

@@ -47,6 +47,24 @@ struct MQTTPresetDef {
 // Braces match topic placeholders ({device}/{iata}); never send this string to the broker.
 static const char MQTT_USERPASS_USERNAME_PUBKEY[] = "{pubkey}";
 
+// True when the broker tears down a live session once its JWT passes exp, so the
+// renewal must proactively bounce the connection to present a fresh token.
+//
+// Default true, because getting this wrong the safe way costs a re-handshake and
+// getting it wrong the unsafe way costs an outage. waev is the exception: its
+// operator confirmed (2026-08-11) that their servers do not disconnect on expiry,
+// so a live session there needs only its credentials refreshed for the next
+// reconnect. waev is also the only preset with a short token_lifetime, so it was
+// the only one bouncing often — every ~47 min, and each bounce's re-handshake can
+// cost ~10 KB of contiguous internal DRAM on a non-PSRAM board.
+//
+// Keyed by name rather than a struct field on purpose: adding a field would mean
+// re-ordering a dozen positional initialisers below, where a mistake is silent.
+static inline bool mqttPresetEnforcesTokenExp(const MQTTPresetDef* preset) {
+  if (!preset || !preset->name) return true;   // custom/audience slots: assume enforced
+  return strcmp(preset->name, "waev") != 0;
+}
+
 static inline bool mqttPresetUsesDevicePubkeyUsername(const MQTTPresetDef* preset) {
   return preset && preset->auth_type == MQTT_AUTH_USERPASS &&
          preset->userpass_username &&

src/helpers/bridges/MQTTBridge.cpp

@@ -2148,7 +2148,16 @@ void MQTTBridge::maintainSlotConnection(int index, unsigned long now_millis, uns
                                             (time_synced && old_token_expires_at >= 1000000000 &&
                                              current_time >= (old_token_expires_at - renewal_buffer));
 
-        if (old_token_expired_or_imminent || !slot.client->connected()) {
+        // Only bounce for exp if this broker actually enforces it. A broker that
+        // leaves live sessions alone past expiry needs the fresh token at the next
+        // reconnect, not now, and the bounce's re-handshake is where contiguity goes.
+        const bool exp_forces_bounce =
+            old_token_expired_or_imminent && mqttPresetEnforcesTokenExp(slot.preset);
+        if (!exp_forces_bounce && old_token_expired_or_imminent && slot.client->connected()) {
+          MQTT_DEBUG_PRINTLN("MQTT%d token renewed, no bounce (broker does not enforce exp)",
+              index + 1);
+        }
+        if (exp_forces_bounce || !slot.client->connected()) {
           // Disconnect + reconnect with fresh credentials, reusing existing client
           // to avoid internal heap leak/fragmentation from destroy/create cycles
           MQTT_DEBUG_PRINTLN("MQTT%d token renewal: reconnecting with fresh credentials", index + 1);