fix(#479): bound what a cover decode may allocate, and what a download may buffer

[guycorbaz]

Closes #479.

The hole

CoverService::process_and_save_bytes decoded with whatever limits the image crate defaults to — 512 MiB. The 10 MiB guard beside it bounds the compressed input, which says nothing about memory: a redundant PNG or WebP of a couple of hundred bytes can declare an RGBA surface of several gigabytes. On the Docker deployment the OOM killer takes the container down, and every in-flight request with it.

Both entry points funnel through this one function: the manual upload (Librarian+, so realistically a mistake or a stolen session) and the provider download, which is the one that matters — those bytes come from Open Library, BnF Couvertures, Inventaire or Google Books, no authentication is involved, and the bulk cover-refetch walks the whole catalogue in a row.

The change

Decode budget. 64 MiB of allocation plus a strict 10 000 px per-side cap. ImageReader::decode computes the output size from the declared dimensions and checks it before allocating, for every format, so a bomb is refused rather than swallowed. 64 MiB is ~16 megapixels of RGBA: a 4032×3024 phone photo still passes, and everything here ends up resized to 400 px wide anyway. The issue suggested measuring against the largest legitimate cover in production; covers are stored already resized, so the original dimensions aren't recorded anywhere — the ceiling is set from what a camera produces instead, with the dimension cap as the cheap early rejection.

Its own error message. The crate says "Memory limit exceeded", which reads like a server fault. From where the librarian sits the file is simply too big to process, and the message now says so and what to do about it. English like its sibling "Image too large: N bytes" — the handler prefixes both with the localized copy.

One layer up, the same shape of hole (beyond the issue's text, flagged here so it is easy to challenge): response.bytes() buffered the entire body after checking Content-Length. That header is the server's claim, not a fact — absent under chunked transfer, and free to lie. A provider that streams without announcing a length could make us buffer indefinitely, which is the same failure the issue is about with one fewer step. The body is now read chunk by chunk and abandoned the moment it crosses 10 MiB.

Coverage

Unit tests in src/services/cover.rs:

• a hand-built PNG that declares 8000×8000 in 200-odd bytes → refused by the allocation budget (this is the issue's crafted-input test);
• one declaring 40 000 px on a side → refused by the strict dimension cap, from the header;
• a 2000×3000 cover → still accepted, so the budget doesn't cost real covers;
• a chunked, never-ending response served from a local TcpListener → the download is cut off with the size-cap error (no HTTP-mock dependency added; tokio was already there).

E2E (tests/e2e/specs/journeys/cover-upload-limits.spec.ts): a librarian uploads the bomb through the real modal, sees the refusal in the modal's error region, and /health still answers — which is the whole point of the issue.

Testing

• cargo clippy --all-targets -- -D warnings — clean.
• cargo test --lib — 1175 passed.
• cargo test --tests --no-fail-fast — no failures.
• CI=true npx playwright test --workers=2 on a freshly reset stack — 333 passed, 2 skipped, 0 failed.

🤖 Generated with Claude Code

https://claude.ai/code/session_01D5cV9QRqQAFpiNKZwZfoNX