Challenge 2: Diagnose a Lost Job — Possible Solution
====================================================================

WHY THIS HAPPENED: BLPOP removes an entry from the list the MOMENT it's
delivered to a worker — not after the worker finishes processing it,
but immediately upon being popped. Once that job left the list, Redis
has no further record of it at all: no "this job was handed out but
not yet confirmed done" state exists for a plain list queue. When the
worker crashed mid-processing, the job wasn't sitting anywhere waiting
to be retried — it had already been permanently removed from the
list the instant BLPOP returned it, so there was nothing left to
reassign to another worker.

WHAT WOULD HAVE PREVENTED IT: a Redis Stream with a consumer group,
using XREADGROUP instead of BLPOP. Reading via a consumer group does
NOT remove the entry from the stream — it marks the entry as
"delivered to this specific worker but not yet acknowledged" (visible
via XPENDING). Only an explicit XACK call, made after the worker
successfully finishes processing, actually marks the entry as done.
If the worker had crashed before calling XACK, the entry would remain
in the pending list, and another worker (or the same one after
restarting) could use XCLAIM to reclaim and finish it — exactly the
crash-recovery capability a plain BLPOP-based list queue never had.