the musl+mimalloc canary showed leak-shaped RSS growth that survived MIMALLOC_PURGE_DELAY=0, so it's live-allocation growth, not v2.x purge retention. mimalloc v2.x has a documented multithreaded peak-RSS pathology (microsoft/mimalloc#1111) reportedly fixed in v3.x — a strong match for ~2,800 thread-local heaps. v3.3.2 is the cheapest discriminator. source layout + override macros (MI_MALLOC_OVERRIDE / MI_LIBC_MUSL) are identical to v2; linkMimalloc unchanged. verified: static musl ELF builds, malloc override active, mi_collect/mi_version present. if v3 still leaks, next isolation is glibc+mimalloc (-Dtarget=...-gnu -Duse_mimalloc) to split allocator-cause from musl-libc-cause; prod glibc is flat, so the growth is allocator/libc, not zlay logic. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>