feat(queue): POST /queues/:name/purge to drain stuck PENDING jobs (refs #13)

[hacka0wi]

Summary

Adds an operator endpoint to clear stuck PENDING jobs from a queue without dropping the queue itself.

POST /api/queues/:name/purge
→ {"success":true, "deleted": 42}

PG backend only — Redis/Kafka/RabbitMQ users have native purge in their broker UIs.

Why

After fixing a flow's code, messages enqueued under the old broken code keep retrying on the visibility timeout cycle (5 min × max_attempts = 15 min) until they hit the DLQ. New enqueues sit behind them. Today the only mitigation is "drop the queue and recreate it" — destructive and loses queue config (concurrency, backoff, etc).

Scope

• ✅ Deletes status='PENDING' rows only
• ❌ Does NOT touch status='PROCESSING' (in-flight) — those age out via visibility timeout if the handler dies
• ❌ Does NOT touch DLQ entries

Refs

Refs #13 — this is a mitigation, not a root-cause fix. Posted analysis as a comment on that issue: the reporter's "stale cached flow code" hypothesis doesn't match the code (loadFlowConfig does a fresh SELECT on every delivery); the most likely root cause is messages stuck in the retry loop. Purge is the operator escape hatch.

Test plan

• Engine builds (go build ./...)
• go vet clean
• CI green
• Manual: enqueue 5 jobs → POST /queues/:name/purge → all 5 deleted, queue config intact