Add SparkMiner support for the Heltec WiFi LoRa 32 V3 board.

[trcjr]

Summary

Add SparkMiner support for the Heltec WiFi LoRa 32 V3 board.

This introduces a new PlatformIO environment and board config for the ESP32-S3 based Heltec V3, including its onboard 128x64 SSD1306 OLED, Vext display power control, onboard LED, BOOT button, and user button wiring.

Changes

• Add heltec-wifi-lora32-v3 PlatformIO environment
• Add HELTEC_V3 board configuration
• Configure OLED pins:
  • SDA: GPIO17
  • SCL: GPIO18
  • RST: GPIO21
  • I2C addr: 0x3C
• Enable Heltec Vext power before OLED init
• Add OLED reset handling during display initialization
• Add onboard LED and button definitions
• Register board in devtool.toml
• Document Heltec V3 in README supported boards table
• Add changelog entry

Validation

Validated on Heltec WiFi LoRa 32 V3:

• Firmware builds with pio run -e heltec-wifi-lora32-v3
• Board boots successfully
• OLED initializes after Vext enable/reset sequence
• SparkMiner runs on ESP32-S3 with hardware SHA enabled
• Board is selectable through devtool metadata

Notes

LoRa/SX1262 hardware is identified in the board metadata but is not used by SparkMiner in this change.

[SneezeGUI]

Thanks for the split, @trcjr — this is exactly the focused piece I asked for on #32: board-only, additive, default_envs untouched, and the pins match the Heltec V3 docs (SDA 17 / SCL 18 / RST 21, Vext GPIO36 active-low, LED 35). The S3 mining fix (#36) is merged now, so this board will mine real shares out of the box.

Two blockers before merge, both small:

1. The LED init lines break every existing OLED build. In src/display/display_oled.cpp the new pinMode(LED_PIN, OUTPUT); digitalWrite(LED_PIN, LOW); sit outside the #ifdef HELTEC_V3 block, but LED_PIN is only defined for ESP32_S3_CYD, ESP32_S3_DEVKIT, and HELTEC_V3 (board_config.h:104,199,419). For esp32-c3-oled, esp32-s3-oled, and wemos-lolin32-oled it's undeclared, so those three envs stop compiling — verified by macro-resolution against your board_config.h; there's no framework fallback in the arduino-esp32 2.0.14 variant headers. Please move those two lines inside the HELTEC_V3 block (your four HELTEC macros all resolve fine from board_config).

2. Serial is dead over the Heltec V3's USB-C. The env omits ARDUINO_USB_MODE/ARDUINO_USB_CDC_ON_BOOT, but the platform's heltec_wifi_lora_32_V3.json injects USB_MODE=1, and with CDC_ON_BOOT defaulting to 0, Serial routes to UART0 on header pins G43/G44 — the board's single USB-C (native S3 USB, no CP2102) then gets zero application serial output: no boot logs, no portal info, no stats in the devtool. Every sibling S3 env sets the pair explicitly (e.g. platformio.ini:236-237, :434-435); two lines fixes it.

Two small ones:

• devtool.toml says "~280 H/s" — the stock S3 counter showed ~272 KH/s with zero valid shares, and the honest rate after fix(s3): mine first SHA in software to fix zero-shares (#28, #10, #5) #36 is ~50-55 KH/s. Drop or fix?
• Add -D AUTO_VERSION="v2.9.5" like the other envs so the banner doesn't report "dev". (USER_BUTTON_PIN is consumed nowhere in the firmware — fine to keep, just documentation.)

Once the two blockers are pushed I'll add heltec-wifi-lora32-v3 to the CI matrix (the OLED envs are in it as of #38, which is how the LED_PIN break was caught) and merge — this closes #17 and retires the board half of #32.

[trcjr]

Addressed all four items in 23a0861:

• Scoped the LED initialization to HELTEC_V3
• Enabled native USB-CDC serial for the Heltec V3
• Corrected the advertised hashrate to ~50–55 KH/s
• Added the v2.9.5 version define

I also verified the Heltec target and the affected OLED environments locally. All five GitHub checks are now green, and the branch has no conflicts. Ready for your CI-matrix update and merge - thanks!