touch: beta_12 — GPS hotfix (enlarge GPS UART RX buffer)

The GPS NMEA UART used Arduino's default 256-byte RX ring (~66 ms of slack at
38400 baud). On the busy touch UI a single long LVGL/map frame stalls the loop
past that window, dropping bytes and corrupting NMEA ephemeris subframes — each
loss costs the receiver ~30 s, turning a ~1-minute fix into several minutes or,
with frequent stalls, never acquiring. Confirmed on-device: peak UART backlog
hit 448 B at idle, well past the 256 B default. Bump the ring to 4096 B (~1 s of
slack) before the core opens Serial1 in sensors.begin(). App-side (no core
re-tag); gated to ENV_INCLUDE_GPS so both touch boards get it. A -DGPS_BUF_DEBUG
backlog probe is included (compiled out of releases).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

release-notes/beta_12.txt

@@ -0,0 +1,8 @@
+# beta_12 — GPS hotfix (one user-facing note per non-blank, non-# line; # lines are section comments)
+
+# --- GPS fix (headline) ---
+Fixed GPS being slow to get a fix — or sometimes never acquiring at all — on the T-Deck. The GPS receives its data over a small serial buffer, and on the busy touch UI a heavy screen redraw could stall long enough to overflow it and drop the satellite data mid-stream, which forced the receiver to start over. The buffer is now 16x larger, so those redraws no longer cost you the fix — acquisition is back to normal (a fix in about a minute instead of several, or none).
+
+# --- A note from Kaj ---
+More and more people are picking up wadamesh lately — which is genuinely awesome — and it's surfacing feature requests and bug reports fast, in big numbers.
+I can't get back to every post in every channel, but I'm on it: I'm prioritising the fixes and quality-of-life improvements, and I'll be working through them later today. Thanks for all the reports and for the patience!

src/main.cpp

@@ -473,6 +473,17 @@ void setup() {
   #error "need to define filesystem"
 #endif
 
+#if defined(ENV_INCLUDE_GPS) && (ENV_INCLUDE_GPS == 1)
+  // GPS UART resilience (slow / never-acquires TTFF fix): the core opens Serial1 for the
+  // NMEA GPS with Arduino's default 256-byte RX ring — only ~66 ms of slack at 38400 baud
+  // (~270 ms at 9600). A single long LVGL/map frame stalls this loop past that, dropping
+  // UART bytes and corrupting NMEA ephemeris subframes. Each corrupted subframe costs the
+  // receiver ~30 s of re-acquisition, so a busy UI turns a ~1-minute fix into several
+  // minutes — or, with frequent stalls, never. A larger ring absorbs the stalls. MUST
+  // precede the core's Serial1.begin() inside sensors.begin(); setRxBufferSize is a no-op
+  // once the UART is already running.
+  Serial1.setRxBufferSize(4096);
+#endif
   sensors.begin();
 
 #ifdef DISPLAY_CLASS
@@ -621,6 +632,22 @@ void loop() {
   }
 #endif
   the_mesh.loop();
+#if defined(GPS_BUF_DEBUG)
+  // Bench diagnostic (build with -DGPS_BUF_DEBUG only; absent in releases): peak GPS UART
+  // backlog accumulated between sensors.loop() drains. A peak above the old 256-byte default
+  // proves loop stalls were overflowing the default ring — i.e. NMEA was being lost, which
+  // is the slow/never-acquires TTFF mechanism. With the 4096 ring above it can climb past
+  // 256 without loss, so a >256 reading is direct proof the fix matters on this unit.
+  { static size_t s_gps_peak = 0; static uint32_t s_gps_log = 0;
+    size_t bl = Serial1.available();
+    if (bl > s_gps_peak) s_gps_peak = bl;
+    if (millis() - s_gps_log > 5000) {
+      s_gps_log = millis();
+      Serial.printf("[GPSBUF] peak=%u B / 5s (old cap 256, now 4096)\n", (unsigned)s_gps_peak);
+      s_gps_peak = 0;
+    }
+  }
+#endif
   sensors.loop();
 #if defined(ESP32)
   // GPS time guard (Ricky Leong's "stuck at 1902"): MicroNMEALocationProvider