fix(api): let 5xx errors through the tool routes' 422 catch-all - #1667

Review notes before merge. Nothing blocking turned up. The new tests fail on the base commit, and the global error handler logs, reports, and answers the rethrown 503/507 with their message and code, so skipping the per-route request.log.error in four routes doesn't lose anything. Scratch cleanup still runs in the inner finally blocks.

Filed as #1671: five catches with the same shape that this PR doesn't touch. They're the passport-photo.ts generate catch (:566), qr-generate.ts, html-to-image.ts, the content-aware-resize.ts prepare catch, and sign-pdf.ts. The issue also sketches a static drift test so the next route can't reintroduce it.

Left to #1640: bridge errors with kind: "operational" and no statusCode (OOM kill, timeout) still come back as 422 from content-aware-resize and passport-photo. Whether those should map to 503 is the policy question #1640 already asks.

Not actioned:

• The 503/507 tests assert the status only, not the body's code. The error handler's SafeError branch has its own tests, so this is thin rather than missing.
• app.close() runs after expect, so a failing test leaves a Fastify instance open. It's inject-only (no socket), and the fork exits anyway.
• No boundary cases (499/500/599/600) in the predicate test. The >= 500 && <= 599 check is simple enough to read.

Thanks @drakeo338. Storage failures in these 13 routes now come back as a 503 or 507 with a real message, not a 422 that blames the user's file. As a side effect, five of them now report a missing decoder correctly too. Merged as submitted, and it ships in the next release. The routes this didn't cover are tracked in #1671 if you want to pick them up.