fix: logger initialization order causes silent log loss on PSRAM init failure

[Kerlynx]

Describe the bug
The logging system (logPrint) is currently used in setup() before the log buffer (logBuffer) is allocated via initLogger() (or ps_malloc). This happens in two places:

1. When psramInit() fails, the code calls logPrint(F("[E] ...")) but logBuffer is still nullptr.
2. When LittleFS.begin() fails (if placed before PSRAM init), logPrint is called before PSRAM allocation.

Although logPrint has a if (!logBuffer) return; guard to prevent crashes, the log messages are silently dropped without any trace in the ring buffer (though they still go to Serial). This makes debugging remote/Web-based log viewing unreliable when early initialization fails.

Proposed Fix
I'm currently working on a refactor to extract the logger into a dedicated module (logger.h / logger.cpp) with the following changes:

• Add bool initLogger() that returns allocation status.
• Restore the correct initialization order in setup():
  Serial → LittleFS → PSRAM → initLogger() → then use logPrint.
• Use goto for unified error handling in setup() to avoid deep nesting.
• Expose const char* getLogBuffer() for Web /log endpoint (instead of exposing raw global pointer).

Status
I have already started working on this in my local branch. I will open a PR referencing this issue within a few days. If you (maintainer) have any preference on the error-handling style (e.g., keep while(1) halt vs. LED blink), please let me know.

Affected Version
Current main branch (as of [date]).

[NCPlyn]

Hi, sorry, but the only way for PSRAM or LittleFS failing to load -> resulting in the unallocated logBuffer, is for the user to buy the wrong ESP32S3 without PSRAM or not following the flash/build instructions properly and selecting the wrong type of chip type.
The problematic PSRAM or LittleFS makes the entire code unsuable and therefore I just make the ESP halt (from the entire code, only for these two things so it's easy to troubleshoot).
Plus tbh, the /log is just a backup endpoint that I think nobody even uses with how many issues I have been troubleshooting for others, debug over Serial0/Serial is still prefered due to core dumps & more....

[Kerlynx]

okey, when it comes to those problems I didn't try to fix it, but keep halting the bad hardware, but emmm, I improved it on the way of my optimise branch, I didn't start the PR because It's still not ready. this time there gonna be some performance improvements, and I'll try to reduce heap allocation since it's really not a good idea on ESP32 chips.