xiao_nrf52 repeater: skip RTC/sensor I2C probing on boot

[strasharo]

Summary

The Xiao_nrf52_repeater build has no RTC or environment sensors wired up, but radio_init() (variants/xiao_nrf52/target.cpp) and simple_repeater's main.cpp unconditionally probe for both over I2C on every boot.

The vendored Wire (TWIM) driver in Adafruit_nRF52_Arduino has no timeout on its blocking wait loops (endTransmission() / requestFrom()), so probing an empty/unpulled I2C bus can hang the device forever instead of just failing the probe - see adafruit/Adafruit_nRF52_Arduino#771 and #2068. I've opened adafruit/Adafruit_nRF52_Arduino#873 upstream with a timeout fix for that driver. Confirmed this exact hang on a Xiao nRF52840 + Wio-SX1262 repeater: it would boot fine once, then go completely silent (no serial, no BLE) after any power cycle - USB/BLE come back if I flash stock Meshtastic on the same board, so it's not a hardware fault.

Change

Adds DISABLE_RTC_AUTODISCOVERY / DISABLE_ENV_SENSORS guards around the two probe call sites. Only DISABLE_RTC_AUTODISCOVERY is set by default on the Xiao_nrf52_repeater environment - no kit for this board ships with an RTC chip, so that probe is pure dead weight. DISABLE_ENV_SENSORS is deliberately not set by default: field-testing turned up a real repeater with an INA219 wired up over I2C for solar/battery voltage monitoring, which is a genuinely common repeater accessory, not an edge case - disabling sensor probing by default would have silently killed that telemetry. Other Xiao_nrf52 environments (companion radio, room server) are untouched and keep both probes on by default, for anyone who's actually wired an RTC/sensor up.

Testing

Flashed to a Xiao nRF52840 + Wio-SX1262 running as BG-SF-Druzhba-2. Before this change: silent after every power cycle, had to disable both probes locally to get a working build at all.

With just the RTC probe skipped and sensor probing left on: boots and responds over serial in ~1-2 minutes (dominated by the sensor scan's own ~15 I2C address probes, each now bounded by the Wire timeout instead of being instant or infinite), advert/stats-*/repeat functions all work, and it's actively relaying real mesh traffic.

Caveat worth flagging for review: on this same board, the sensor scan intermittently reports 3-4 more telemetry channels than there are real sensors, all reading exactly zero (matches the Voltage/Current/Power shape of INA-family chips and plain-zero temperature channels) - i.e. false-positive I2C detections, not real hardware. This appears to be a signal-integrity issue with this specific board+radio combo (matches community reports of a marginal/underpulled I2C bus - see the discussion in #2068) rather than something this PR introduces: the same "success returned on a phantom ACK" behavior exists in stock Wire too, it was just never reached before because the RTC scan hung first. Not something I can fix from the MeshCore side; flagging in case it's useful context, or if EnvironmentSensorManager's detection loop wants a stricter check (e.g. an ID-register readback) before accepting a device as found.

It goes further than false detections, too: on the real INA219 at its correct address, individual reads intermittently come back either as exactly 0 or as physically implausible values (e.g. 21V on a single-cell LiPo) rather than cleanly failing - a transaction that completes without EVENTS_ERROR isn't a guarantee the data is correct on this bus. I tried mitigating this in query_ina219() with a retry-until-plausible-range loop and it made things worse: past a fairly small threshold of added delay() (somewhere between ~100ms and ~160ms of retries), the repeater's telemetry responses started failing outright ("unreachable"/timeout at the mesh layer) rather than just being slow, even though the board stayed fully healthy and reachable for every other command. Reverted that attempt entirely - noting it here so nobody else loses time on the same approach. Whatever calls querySensors() appears to be on a tighter timing budget than a few hundred ms of blocking I2C retries can afford.

The real underlying hang bug is the missing timeout in Adafruit's Wire driver - see adafruit/Adafruit_nRF52_Arduino#873, since it also affects other Xiao_nrf52 environments that do use I2C, and any other nRF52 board built on that core.