M5.6a: memory report (library.memory, ui.inspect memory) and opt-in DHAT heap profile

Per-cache bytes: decoded thumbnail/preview/full sources, rendered previews,
GPU device buffers (allocated/pooled/retired), loupe stage caches (CPU and
GPU) and textures. lightcraft-cli --features dhat-heap adds live/peak heap and
writes dhat-heap.json.

Baseline (14 raws, loupe, 12 steps): peak RSS 1.9-2.3 GB, footprint 2.5-2.6 GB;
heap peak 634 MB after import (probes decode every raw), 930 MB during grid
thumbnails (parallel decodes); GPU free pool grows to 2 GB (exact-size reuse).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/control-protocol.md

@@ -20,7 +20,7 @@ mode ([mcp.md](mcp.md)) is a thin layer over this channel. Implementation:
 | `engine.execute` (alias `ui.menu.invoke`) | `{command, params?}` | Run any engine or UI command (see `engine.commands`) |
 | `engine.commands` | — | Engine + UI commands: id, label, menu, shortcut, params doc, enabled |
 | `ui.menu.list` | — | Menu entries |
-| `ui.inspect` | — | UI state, window, canvas/image rects, active photo, selection, perf, status |
+| `ui.inspect` | — | UI state, window, canvas/image rects, active photo, selection, perf, status, memory (bytes per cache, see `library.memory`; plus stage caches and textures) |
 | `ui.widgets` | `{filter?}` | On-screen widgets `{id, rect: [x, y, w, h]}` (screen points) |
 | `ui.clickWidget` / `ui.dragWidget` | `{id, count?, fx?, fy?}` / `{id, toX?, toY?, dx?, dy?, steps?}` | Real egui input on a widget |
 | `ui.move` / `ui.click` / `ui.drag` | `{x, y, count?, button?}` / `{x, y, toX, toY, steps?}` | Raw pointer input, screen points |

docs/gpu-pipeline.md

@@ -88,6 +88,19 @@ the device on their first GPU render. `lightcraft_gpu::ready()` asks without blo
   one is rendered (decoded source kept, view render cached): stepping through photos shows the
   developed image in ~50 ms.
 
+## Memory (M5.6)
+- `library.memory` reports what the engine's caches hold (decoded thumbnail / preview / full-size
+  sources, rendered previews) and the GPU renderer's device buffers (allocated, of which pooled
+  and retired); `ui.inspect` → `memory` adds the loupe's stage caches (CPU images, GPU buffers)
+  and the textures.
+- Heap profile: build `lightcraft-cli` with `--features dhat-heap`; `library.memory` then also
+  reports live/peak heap bytes and the run writes `dhat-heap.json` (`LIGHTCRAFT_DHAT_FILE`), whose
+  allocation sites at the peak (`t-gmax`) show who holds the memory.
+- Measuring the scenario (import 14 raws from `corpus/raw`, open the loupe, step 12 times):
+  `/usr/bin/time -l lightcraft-cli snapshot <files> --script steps.jsonl -o out.png` → "maximum
+  resident set size" and "peak memory footprint". Run it several times: the high-water mark is
+  noisy (allocator caching, scheduling). On Apple silicon GPU buffers count in the footprint.
+
 ## Open items
 - Keep the loupe texture on the GPU (render into an `egui-wgpu` texture on eframe's device instead of
   reading back); share the device with eframe.