Probe with the software I2C port in every autodetect block until the board is confirmed

[ainyan03]

Summary

Several autodetect blocks still opened a hardware I2C port to identify the board and handed it over only when a board matched. When none did, the ESP32 AXP probe left I2C_NUM_1 open on G21/G22. With the ESP-IDF i2c_master driver the pins stay reserved, so M5Unified opening the same pins on I2C_NUM_0 for a Core BASIC logs

W (508) i2c.common: GPIO 21 is not usable, maybe conflict with others
W (508) i2c.common: GPIO 22 is not usable, maybe conflict with others

and I2C_NUM_1 was left unusable for the application. The other blocks released the port on a miss but still touched the peripheral and pins of a board that was not there.

Every block now probes on the software port (probe_i2c_port) and opens the hardware port right after the board is confirmed, matching what the newer chips already did. A small probe_i2c_t helper bundles the sequence so all eleven blocks follow it, including the pre-existing soft probe blocks (Tab5, NessoN1, ToughC5, CoreMatrix):

• The software port routes SDA/SCL to plain GPIO output while probing. When the hardware port was already opened by the application (shared bus, I2C: share a port the application already opened instead of taking it over #269), init() leaves the pins as the owner configured them, so the GPIO routing left behind by the probe would cut the port off from its pads and every later transfer from the backlight and touch drivers would fail. The probe backs up both pads before it starts and restores them right after it is released, on the handover and on the miss path alike.
• PaperS3, StickS3 and NessoN1 test the pull-ups on SDA/SCL with gpio::command before probing, which already routes the pads to GPIO, so those blocks hand the backup they took before the test to the probe.
• The UnitC6L block opens its port only once the panel matched.
• When the hardware port cannot be opened after the board was confirmed, a warning names the port and pins (the identification is kept, since dropping it would lose the display as well).

Verification

Detection, display, backlight sweep, In_I2C scan and touch, compared against develop on the same boards:

Board	Framework	Result
Core BASIC	ESP-IDF v6.0.2	warnings gone, In_I2C/Ex_I2C unchanged
Core2 v1.1	ESP-IDF v6.0.2	identical to develop
Tough	ESP-IDF v6.0.2	identical to develop
CoreS3	ESP-IDF v5.5.4	identical to develop
StickS3	ESP-IDF v5.5.4	detection, display, In_I2C OK
UnitC6L	ESP-IDF v5.5.4	detection, display, In_I2C OK
PaperS3 / PaperMono / PaperColor	Arduino	identical to develop
Tab5	Arduino	detection, display, In_I2C OK
ToughC5	ESP-IDF v5.5.3	detection, display, In_I2C OK

Shared bus: with the application opening I2C_NUM_1 on the internal bus through i2c_new_master_bus() before M5.begin(), Core2 and CoreS3 keep the backlight, touch, In_I2C (4 / 9 devices) and the application's own transfers working. Without the pad restore, the same setup left In_I2C at 0 devices, broke the application's transfers, and misidentified the CoreS3 as CoreS3SE.

Builds: ESP32 / ESP32-S3 / ESP32-C6 / ESP32-C5 / ESP32-P4 (ESP-IDF and Arduino).