Lulu Status Webhook

Lulu pushes every print-job status change here.

Unauthenticated by design — the caller is Lulu, not a signed-in user — so the HMAC signature IS the authentication and is checked before the body is parsed or trusted for anything.

RESPONSE DISCIPLINE. Lulu retries a failed delivery five times and then flips the webhook inactive. So this returns 200 for everything it has genuinely handled OR genuinely cannot ever handle (unknown topic, a job id that is not ours), and reserves non-200 for the two cases where a retry is the right answer: a bad signature (401) and our own storage failing (500). An order we do not recognise is not an error — sandbox and production accounts can point at the same URL.

This is additive: GET /print-orders/{id} still refreshes from Lulu on read, so a missed or disabled webhook degrades to the polling behaviour rather than leaving orders stale.

ONE URL PER LULU ENVIRONMENT. Each deployment holds exactly one Lulu secret (sandbox or production, following LULU_API_BASE) and verifies with it. A delivery signed by the OTHER environment's account is a 401 here, and five of those deactivate that account's hook. So the sandbox and production accounts must point at different deployments — which is what the self-heal cron does, registering only its own account at its own PUBLIC_API_BASE. Never register both at one URL by hand.