Job queue: decide whether to ship one, or state that Temporal is the answer

[btravers]

From a gap analysis against NestJS and AdonisJS.

@btravstack/amqp is broadcast messaging, not a job queue, and the distinction matters more than it looks. examples/order-amqp-contract's own TSDoc draws it: "AMQP carries announcements, orchestration carries intent" — a publisher does not know who is listening, and a consumer reacts to a fact somebody else already committed.

A job queue is the other thing: a caller enqueues work it wants done, with a handle on it. That needs primitives AMQP's contract deliberately does not model —

• delay / schedule-at, beyond the DLX ttl-backoff retry the contract uses for failures;
• priority;
• deduplication / idempotency keys;
• per-job attempt budgets distinct from the queue's retry config;
• progress and result read-back — @btravstack/amqp has an rpcs half, but that is request/response, not a durable job whose result outlives the caller.

Nest ships @nestjs/bull for this; Adonis leaves it to the community. Note the honest alternative: for anything needing durability, retries and a result, @btravstack/temporal may already be the answer — a workflow is a durable job with a result. The issue is worth opening precisely so that gets decided rather than assumed, because "use Temporal" is a legitimate outcome and saves a whole package.

If a queue runtime is built, it is a fourth Runtime like the scheduler (#60): a unit per job attempt, drain stopping new pulls and waiting for in-flight ones, Serving.info publishing the queues consumed.

Acceptance

• A decision recorded somewhere durable: does this repo ship a job-queue runtime, or is Temporal the stated answer for durable work?
• If shipped: a Runtime on the same terms as the other three, with delay, priority, dedupe and per-job attempts addressed explicitly rather than inherited from a broker's retry config.
• If not shipped: a short note in the root CLAUDE.md saying so, next to the AMQP/Temporal split, so the question is not re-asked.