BOARD_SUPPORTS_ESPIDF is a literal set of OSS board kinds and it gates
both the toolbar's ESP-IDF option and setBoardLanguageMode, so no overlay
board could ever be switched into ESP-IDF: loadExample called
setBoardLanguageMode(id, 'espidf') for an `languageMode: 'espidf'` gallery
example, the guard returned early, and the example opened in Arduino mode
with the toolbar saying "Arduino C++". It stayed invisible because the
backend sniffs `app_main` and compiles those sketches as pure IDF anyway —
until a board with no Arduino FQBN at all hit it, and the run died in the
browser at "No FQBN for board kind" before any request left the page.
- ProBoardDef.supportsEspIdf registers the kind into BOARD_SUPPORTS_ESPIDF,
the same way supportsMicroPython already did for MicroPython.
- ProBoardDef.espidfFqbn + BOARD_KIND_ESPIDF_FQBN + fqbnForLanguage give the
IDF lane a target for a board whose Arduino FQBN is null (the ESP32-C5
kits: no arduino-esp32 core supports the C5, and the backend refuses that
target for Arduino on purpose, but idf.py builds it fine). Both compile
sites resolve through it instead of reading BOARD_KIND_FQBN directly.
- The language select shows when EITHER alternative mode exists (the P4 is
ESP-IDF but not MicroPython, so it had no select at all), hides options
the board does not support, and hides Arduino for a board with no FQBN.
- addBoard no longer seeds an Arduino-less board into 'arduino', where it
could never compile and the select would show a value it does not carry.
Regression test: overlay-espidf-mode.test.ts.
87101175ce