feat: Enable GPS on RAK 1W kit + fix RAK12500 i2c-ublox polling (affects all RAK ublox boards) 🤖🤖

[disq]

Re-application of #2401

Tested on RAK3401 + RAK12500 in SLOT A (UART / I2C Communication)
At the time of testing, the RAK19007 board also had RAK13302 (1W) and RAK12002 (RTC)

---

Changes beyond the original #2401 re-application

RAK3401 GPS enablement (b6e6730f)

• Restore -D RAK_BOARD on [rak3401] (removed in the feat: Enable GPS on RAK 1W kit #2401 revert due to "RadioLib error -707"). The real cause was rakGPSInit()'s WB_IO4 fallback probe pulsing pin 4 (= SX126X_RESET on RAK3401) LOW for 500 ms, hard-resetting the radio after radio_init(). Fixes below make RAK_BOARD safe to re-enable.
• rakGPSInit() WB_IO2 probe: WB_IO2 also controls the 3V3_S switched peripheral rail; a failed probe left it as INPUT, dropping the rail (and the RTC/display/GPS with it). Restore WB_IO2 HIGH before falling through to the WB_IO4/WB_IO5 probes.
• Add -D FORCE_GPS_ALIVE on the RAK3401 base env so stop_gps() can't later pull gpsResetPin (which may resolve to the radio reset / rail pin) LOW after init.

Stale PVT data fix (b6e6730f)

• RAK12500LocationProvider passed maxWait of 2/8 ms to the ublox getters — below the I²C response window, so polls timed out and the SparkFun library returned stale/garbage PVT (observed: a current latitude paired with a longitude from a previous fix). Bumped to a 250 ms ceiling.
• Switched getAltitude() (height above WGS84 ellipsoid) to getAltitudeMSL() for more intuitive altitude.

Cold-start false fix (f2ad72e6)

• Require both gnssFixOK and fixType == 3 before reporting coordinates. Ublox reports gnssFixOK == true with bogus almanac-derived coords during cold start; requiring a 3D fix filters those out.

Main-loop / button responsiveness fix (a13098a5)

• The 250 ms maxWait above, combined with RAK12500LocationProvider::loop() running on every main-loop iteration, meant the loop spent most of its time blocked on redundant I²C polls (the GNSS solution only updates at the 1 Hz nav rate). This made the AIN1 button sluggish and dropped double-clicks ("prev").
• Throttle the poll to ~1 Hz inside the provider, and gate all field reads on a single getPVT(250) (returning early on a timeout so no getter fires its own ~1100 ms default poll on a stale cache). The throttle lives in the provider rather than the shared outer loop because the serial/NMEA providers need loop() every iteration to avoid dropping bytes.

Debug-print cleanup (c9dfd1bd)

• Dropped a duplicate lat/lon debug print and throttled the remaining one (~every 10th update tick).

Merged up to date with dev.

---

Scope / affected boards

The RAK12500LocationProvider and rakGPSInit() changes compile under RAK_WISBLOCK_GPS (ENV_INCLUDE_GPS && RAK_BOARD && !RAK_WISMESH_TAG), so they affect every RAK i2c-ublox GPS board, not just the RAK 1W kit: rak3401, rak4631 (all envs except the two rs232 bridges), and gat562_30s_mesh_kit. (gat562_mesh_watch13 has GPS disabled; rak_wismesh_tag is excluded.)

Implications for the already-shipping RAK4631 / GAT562 boards:

• 1 Hz poll throttle — strictly beneficial; the GPS poll previously ran on every main-loop iteration. (The sluggish-button symptom was only visible on RAK3401 because of its AIN1 analog button, but the redundant blocking affected all of these boards.)
• fixType == 3 gating — coordinates are now withheld until a 3D fix (filters cold-start false fixes).
• getAltitudeMSL() — altitude is now height above mean sea level instead of the WGS84 ellipsoid.
• rakGPSInit() WB_IO2 rail-restore — safety fix for a failed first probe dropping the 3V3_S peripheral rail.

-D FORCE_GPS_ALIVE is scoped to the rak3401 env only, so stop_gps() behavior is unchanged on the other boards. Worth a smoke-test on RAK4631 + i2c GPS before merge.