Fix wifi check

[pm-ju]

Name/Affiliation/Title
Name: Pritish Mahato Affiliation: Jadavpur University(RISC-V) Title: Student Contributor

Purpose of the PR:
This PR adds runtime assert checks to prevent the WiFi module from being used when it was not enabled in the firmware configuration. This addresses a recurring bug where attempting to use WiFi functions (e.g.,
ControllerWiFiConnect, ControllerWiFiPost) without WiFi being initialized caused silent failures, the I2C commands would be sent to the ESP32 with no error feedback to the developer.

Changes:

1. STM32 controller WiFi library (stm32/lib/controller/): Added a wifi_initialized static flag and a new ControllerWiFiSetInitialized() function. An assert(wifi_initialized) guard is placed in WiFiCommandTransaction(), the single choke-point for all ControllerWiFi* functions, ensuring any accidental WiFi usage when not enabled immediately halts with a descriptive assert message.

2. STM32 WiFi application (stm32/Src/wifi.c): Calls ControllerWiFiSetInitialized() at the start of WiFiInit() to arm the guard.

3. ESP32 module handler (esp32/lib/module_handler/src/module_handler.cpp): Added assert(false) when an I2C command arrives for an unregistered module, replacing the previous behavior of silently logging and returning.

Development Environment:
OS: Windows 11
PlatformIO: version 6.1.19
Hardware version: N/A

Test Procedure:
This is a defensive programming fix, the asserts fire only when the WiFi module is misused (called without being enabled). Normal operation is unaffected.

1. Build verification: All STM32 and ESP32 environments compile successfully with pio run in both stm32/ and esp32/ directories.

2. Existing unit tests: All existing tests in pio test -e tests (STM32) continue to pass since they don't invoke the WiFi controller path without initialization.

3. Manual verification: Flash the STM32 with a LoRa-only user config. If any code path accidentally calls a ControllerWiFi* function, the firmware now halts at the assert instead of silently failing over I2C.

Additional Context:
The bug was encountered twice by the maintainer when attempting to use the WiFi module without it being enabled in the firmware. The fix is minimal and surgical ,a single assert() in the WiFiCommandTransaction() choke-point guards all 11 public ControllerWiFi* functions without modifying any of their signatures or behavior.

Task List:

• Update CHANGELOG.md
• Static code analysis passes
• [ ✓] All environments can be built
• [ ✓] All tests pass
• [ ✓] Clear documentation for new code

Closes #272

[jmadden173]

Assert statements shouldn't be used in this case. We don't want to hard fault the mcu. Instead propagating the error up in the program to "soft" handle it.