esp32-heap-discipline

# ESP32 Heap Discipline Memory rules for `esp32/` firmware. Adapted from crosspoint-reader's `heap-discipline` skill to AgentDeck's multi-board reality. This is the procedure you run while writing firmware and the gate before handing it back. ## The board split — know which world you're in AgentDeck firmware targets two memory regimes. Check the board macros first. - **PSRAM boards** — `BOARD_BOX_86`, `BOARD_IPS35`, `BOARD_AMOLED`, `BOARD_IPS10` (ESP32-S3 / -P4, 8–32MB PSRAM). Large canvases/caches go in PSRAM (`ps_malloc` / `MALLOC_CAP_SPIRAM`). **But** per-pixel / LVGL draw buffers and PPA rotation buffers must stay in **internal SRAM** (`MALLOC_CAP_INTERNAL`): PSRAM writes are ~30× slower, so a PSRAM draw buffer makes every widget render crawl (see the IPS10 rationale in `esp32/src/ui/display.cpp`). Plenty of total RAM here; the constraint is *write latency and internal-SRAM headroom*, not bytes. - **No-PSRAM boards** — `BOARD_TTGO` (classic ESP32, ~160KB heap), `BOARD_ESP32_C6_147` (single-core RISC-V), `BOARD_LED8X32` (TC001). This is crosspoint's world: every allocation matters and **fragmentation, not total usage, is what kills the device.** Free heap can read fine while the largest free block is too small for the next alloc. Optimize for not leaving holes. The canvas/buffer code already encodes this split (`renderer.cpp::init` uses static pre-allocated buffers on TTGO/C6 and `ps_malloc`+SRAM fallback elsewhere). Match the existing pattern; d...