BullMQ on Upstash Redis: native protocol with TLS, not REST

# BullMQ on Upstash Redis: use the native protocol

## Why not REST

Queue consumers rely on blocking pops (BLPOP/BRPOP), which REST
does not support. BullMQ speaks RESP, so point it at the native
endpoint.

## Connect

BullMQ uses ioredis under the hood. Configure it like any
TLS-required Redis:

- Host: your Upstash endpoint
- Port: your Upstash port
- Username: default
- Password value your console token
- TLS: enabled

## Settings that matter on serverless Upstash

- Keep producers and workers as long-lived processes. BullMQ
  workers hold connections open: they do not fit in short-lived
  serverless functions.
- Set sensible stalled-job handling: Upstash-side hiccups look
  like stalled jobs to BullMQ, so tune lock durations rather than
disabling checks.
- Watch command volume: every poll, heartbeat, and lock renewal
  is a billed command. Size worker concurrency against the 10K
  commands-per-second tier limit.

## Alternatives on pure serverless

If you have no long-lived workers, BullMQ is the wrong queue.
Consider Upstash QStash for HTTP-based background jobs, or poll
with REST from scheduled functions.

## Verify

Enqueue a test job, watch a worker pick it up within the expected
poll window, and confirm completion lands in the queue events.
Check the console command graph for the expected per-worker
baseline.