ESP32-S3 support: WROOM-1-N8R8 config and stability fixes

[laith-dosinfection]

Summary

This branch adds working ESP32-S3 support, tested on an ESP32-S3-WROOM-1-N8R8 module with a PCM5102A DAC. Built and verified with ESP-IDF v4.4.8.

• sdkconfig for ESP32-S3-WROOM-1-N8R8: Quad SPI flash (DIO), octal PSRAM (8MB), correct toolchain prefix
• Cross-target build fix: Replace hardcoded xtensa-esp32-elf-objcopy with ${CMAKE_OBJCOPY} in CMakeLists.txt so the build works for both ESP32 and ESP32-S3
• Fix heap corruption in captive portal redirect: 1-byte buffer overflow in http_server_handlers.c — allocated buffer didn't account for trailing / in redirect URL, corrupting the heap tail marker and crashing on first WiFi setup connection
• Fix reboot loop when no LMS server is present: When running AirPlay/Spotify without an LMS server, slimproto now retries discovery in the background instead of rebooting the device every ~3 minutes. AirPlay, Spotify Connect, and BT sinks operate independently of LMS

Tested with AirPlay streaming — stable operation over multiple hours with no reboots.

Happy to keep this as an S3-specific branch if that makes more sense than merging into the main line. Appreciate all the great work on this project!

Test plan

• Build with ESP-IDF v4.4.8 targeting esp32s3
• Flash and boot on ESP32-S3-WROOM-1-N8R8
• PSRAM detected and working (64Mbit octal)
• WiFi AP captive portal works without crashing
• AirPlay streaming stable (no reboot loop)
• Spotify Connect service advertises correctly
• Track changes, volume control, metadata all working

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request migrates the project target from ESP32 to ESP32-S3, involving extensive updates to the SDK configuration, toolchain prefixes, and flash settings. It also refactors the Squeezelite execution logic to avoid system reboots when a server is unavailable, implementing background retry loops instead. Additionally, a potential buffer overflow in the HTTP redirect handler was corrected. Review feedback highlights opportunities to improve resource management by deleting finished tasks rather than suspending them and suggests enhancing system responsiveness by replacing long sleep intervals with more granular checks of the running state.

[gemini-code-assist]

Using vTaskSuspend(NULL) keeps the task and its allocated stack memory in the system indefinitely. Since the task has finished its execution and is not intended to be resumed, it should be deleted to free up resources. vTaskDelete(NULL) is the standard way to terminate a task in ESP-IDF and ensure its resources are reclaimed by the idle task.

        vTaskDelete(NULL);
    } else {
		cmd_send_messaging("cfg-audio-tmpl",MESSAGING_ERROR,"Correct command line and reboot\n");
        vTaskDelete(NULL);

[gemini-code-assist]

The sleep(30) call blocks the task for a significant duration, making it unresponsive to changes in the running flag (e.g., during a system shutdown or service stop) until the timer expires. Consider implementing a more responsive wait, such as a loop with shorter delays (e.g., 1 second) that checks the running flag frequently, or using a semaphore/event group with a timeout.

[gemini-code-assist]

Similar to the initial discovery loop, this 30-second sleep prevents the task from exiting promptly if the service is stopped or the system is shutting down. A more responsive waiting strategy is recommended to improve system shutdown latency.