[beetlebugorg]

What

The error image follows DimsStripMetadata. A failed request returns an image with no EXIF, no color profile, and no timestamp. A successful response already does.

Why

dims_cleanup sends the error image straight to dims_send_image. That path skips dims_process_image. The default strip runs only in dims_process_image, so DimsStripMetadata did not apply to the error image on any endpoint.

The PNG kept a tIME chunk and three date: text chunks that record the wall clock second. Two error images built in one request pair differ whenever the pair crosses a second boundary. Four cases compare those bytes and fail on that boundary: TestCropOffsetOnTheEdge, TestCropXOffsetOutsideImage, TestCropYOffsetOutsideImage, and TestSvgExternalReferenceIsRefused. The first failed about one run in thirteen.

dims5.c calls dims_cleanup, so one change covers /dims3/, /dims4/, and /dims5/.

Verify

make -C test test
make -C test test-update
make -C test sanitize

278 cases pass, every golden file reproduces, and 105 sanitizer cases report no finding. I measured 200 paired error image requests: every pair returned identical bytes. The same measurement on the parent commit returned one differing pair in forty.

Breaking

The error image is 4089 bytes where it was 4337. A caller that reads Content-Length from a failed request sees the smaller value. A successful response is byte for byte unchanged, and all 91 golden files reproduce.