docs: findings on moving the mbedTLS record buffers to PSRAM

[davelee98]

Working notes on whether od_tls_reserve_records()'s two 17,408 B record slots (34,816 B of internal DRAM, held from boot) can move to MALLOC_CAP_SPIRAM. Documentation only — no code change.

Verdict: safe with caveats, on S3. The concern that would have been a hard blocker — hardware crypto DMA being unable to reach external PSRAM — does not apply to ESP32-S3.

Verified against the pinned S3 SDK (Arduino 3.3.9 / IDF 5.5.4):

Claim	Result
CONFIG_MBEDTLS_HARDWARE_AES / _SHA / _MPI	all three =y
CONFIG_MBEDTLS_AES_USE_INTERRUPT	=y
SOC_PSRAM_DMA_CAPABLE	1
SOC_AES_GDMA, SOC_SHA_SUPPORT_DMA	(1)

The generic "don't do this on classic ESP32/C3/C6" caveat is moot here: TLS compiles only under OPENDISPLAY_HAS_WIFI, set on exactly five envs, all S3.

Caveats recorded:

• AES still needs a small internal bounce buffer for unaligned interior record pointers, so this does not fully decouple TLS from the internal heap. Its size is flagged unverified — Arduino ships prebuilt libs, headers only.
• s_tlsSlotBusy[] is non-atomic under a global allocator hook that catches every mbedTLS caller, not just the LAN TLS server. Pre-existing and independent of PSRAM; the doc recommends fixing it first so a concurrency bug and a placement bug can't be confused.
• Record buffers hold plaintext, which PSRAM puts on the external memory bus. A threat-model decision, not a blocker.

Also notes a discrepancy found in passing: src/wifi_service.h:61 and src/wifi_service.cpp:275 both assert CONFIG_SPIRAM_IGNORE_NOTFOUND=1, which is not present in the pinned S3 sdkconfig. Either set somewhere I didn't find, or both comments are stale.

All file:line citations were re-verified against main HEAD 976f0c2 (the investigation was originally done on a feature branch where the line numbers differ).

https://claude.ai/code/session_01Dr3hFvUyZUaLvadPLQcvyz