feat: add in-memory queue to serialize the redeploy webhook

[Zareix]

Problem

POST /api/stacks/redeploy calls redeployAllRunningStacks() directly and awaits it. When a registry fires several webhooks in a burst (one per pushed image), each request starts its own full pass — two docker compose up runs can hit the same stacks concurrently, and N redundant passes run for a single burst.

Change

Adds a generic in-memory task queue built on p-queue (src/lib/queue.ts), plus a thin redeploy consumer (src/lib/redeploy-queue.ts) that:

• serializes redeploy passes (at most one at a time);
• coalesces bursts by key (an in-flight redeploy is shared instead of queued again).

The route now returns 202 Accepted immediately with the queue status instead of blocking until all stacks finish, and GET /api/stacks/redeploy exposes the current { running, queued } state.

createTaskQueue is generic and reusable for any async task (prune, image pulls, …).

Alternative (SQLite-persistent)

See #53 for the same feature backed by bunqueue (persistent, retries, DLQ).

Notes / trade-offs

• In-memory: the queue is lost on restart. Acceptable because a redeploy is idempotent and the next webhook catches up.
• Each instance manages its own Docker host, so a per-process queue is the right granularity.
• tsc --noEmit is clean for these changes; the client + SSR bundles build fine. The final Nitro externals-tracing step fails on a pre-existing, unrelated issue (missing optional native dep cpu-features under dockerode → docker-modem → ssh2).
• Run bun run check before merging.