sensors: fix millis() rollover that stalls GPS time-sync on long-uptime nodes

[benskigomez]

Problem

MicroNMEALocationProvider and EnvironmentSensorManager store a future millis()
deadline in a signed long and compare it with a naive millis() > deadline:

long next_check = 0;
...
if (millis() > next_check) {
    next_check = millis() + 1000;
    // re-arm 30-min time-sync + set RTC from GPS here
}

millis() is uint32_t. After the ~24.8-day sign flip the stored deadline sits above
the wrapped millis(), so millis() > next_check stays false and the whole block never
runs again. Because both the periodic re-arm and the actual _clock->setCurrentTime()
live inside that block, GPS→RTC time-sync (manual and automatic) stops permanently until
reboot — matching the "ran for weeks then the clock drifted / node fell off the map"
reports in #2786 (this is distinct from, and complementary to, the missing-clock-in-
constructor cause some boards also have). The same pattern in
EnvironmentSensorManager::loop() (next_gps_update) freezes the location cache refresh.

Fix

Use the wrap-safe signed-difference compare already used by Dispatcher::millisHasNowPassed
((long)(millis() - deadline) > 0) and make the deadlines unsigned long:

• src/helpers/sensors/MicroNMEALocationProvider.h: next_check
• src/helpers/sensors/EnvironmentSensorManager.cpp: next_gps_update

Valid for all intervals well under 2^31 ms (here 1 s), on every platform.

Two tiny cleanups ride along in the same file: reorder the MicroNMEALocationProvider
constructor init-list to declaration order (silences -Wreorder), and drop the always-true
if (_claims > 0) guard in claim() (it always runs right after _claims++).

No functional change beyond fixing the rollover; no API/ABI surface touched (all changed
symbols are private/local).