feat: add in-memory redeploy queue backed by bunqueue

[Zareix]

What

Alternative implementation of the redeploy queue using bunqueue (embedded, in-memory) instead of p-queue. See #52 for the p-queue variant.

Change

• Adds bunqueue (queue + worker in one object, embedded in the Bun process).
• src/lib/redeploy-queue.ts: a Bunqueue instance (in-memory — no dataPath) with:
  • embedded: true — no broker, runs in-process;
  • concurrency: 1 — serializes redeploy passes;
  • retry (exponential backoff, 3 attempts) — failed passes are retried;
  • deduplication (10s TTL) — repeated webhooks within the window coalesce into one job.
• src/routes/api/stacks/redeploy.ts: POST enqueues a job and returns 202 immediately; GET reports queue state (active/waiting).

vs #52 (p-queue)

	#52 (p-queue)	this (bunqueue)
Persistence	in-memory	in-memory
Retries / DLQ	none	built-in retry + DLQ
Priorities / events	concurrency, priority, events	priority, events, dedup, rate-limit, circuit-breaker
Dependency	p-queue (2 tiny deps)	bunqueue (croner + msgpackr)
Maturity	2900+ dependents, feature-complete	young (few dependents)

Notes

• bunqueue/client is Bun-only (bun >= 1.3.9); the app already runs on Bun.
• A SIGINT/SIGTERM handler calls redeployQueue.close() for a clean worker shutdown.
• Optional: pass dataPath to persist jobs to SQLite instead (survives restart).
• 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).