[wefio]

Why

220 invocations died at the 120 s ceiling on 2026-10-29 carrying 762-1014 MB, and the log
cannot say what that was. Every one of those rows is a killed request, so the sample is
conditioned on the outcome: it cannot separate a container baseline from a heap that grew
inside a warm instance. A narrow band across killed requests is also what a retry loop
plateaued by GC looks like, so "no row below 700 MB" is not evidence for a baseline.

The code can only account for about 32 MiB of in-flight peak per partition operation (8 MiB
image + 8 MiB WASM copy + 8 MiB export + 8 MiB previous image), and partitions are handled one
at a time, so there is nothing to optimise until the baseline is known.

What this adds

field	why it decides something
baseline (read at module evaluation, before SQLite)	if it is already large, the platform figure includes the container and the V8 reservation, and our allocations are noise
seq, uptime_s	a leak only means anything inside one warm instance; a trend has to be read against request number
mem.{heapUsed, external, arrayBuffers}	JS objects vs byte buffers; a WASM linear memory that only grows shows up in the latter
sqlite.{live_databases, live_image_mb, high_water_*, wasm_linear_mb}	whether images outlive their part, and how far the linear heap has grown

Sampling: one request in twenty by default, every request with NMG_MEM_TRACE=1, none with
=0. Fast requests are sampled on purpose - the incident sample contained only hung ones.
The 60 s slow-request report and /admin/status carry the fields unconditionally, so memory can
be watched during a live deployment instead of only after a kill.

Read-out

what you see	conclusion
baseline.rss already ~800, flat rss as seq grows	platform figure includes the container; stop chasing memory, the 120 s kill was the real problem
heapUsed climbing with seq, no fall at exit	JS objects accumulate (manifest / parsed body)
external/arrayBuffers climbing with seq	WASM linear memory or byte buffers are not released
live_databases > 1 or high_water_image_mb > 16	images outlive their partition
saw-tooth at exit but platform figure still high	concurrency, not a leak

Also

Once the image is copied into the WASM heap the SQLite module owns it (FREEONCLOSE), so the
JS copy is now dropped while the connection is still open rather than at the end of the request.

Verification

onlion npm run verify: 35 PASS (new test:mem asserts the policy: nothing when disabled, one
in twenty by default, every request when forced, and that a baseline exists). eslint, prettier
and the complexity gate are clean for every file touched here.