fix: bind durable DLQ consumer so retry drains on workqueue stream

[ecv]

Summary

The dead-letter stream allows only one consumer per subject filter, and the retry loop created a fresh overlapping one on every batch, so it usually could not attach and no failed activity event was ever retried.

The backlog has grown from 177 events to 420 with no consumer attached at all, and each one is a user-visible activity that will never render.

One durable consumer is now provisioned for that stream, both processor replicas bind it and compete for messages, and events waiting on backoff are deferred rather than redelivered immediately.

Policy-triggered retry can no longer narrow its fetch server-side, so it scans forward under a time cap and defers the events it skips.

Test plan

• Five JetStream tests cover each failure mode, and each one fails when its fix is reverted
• Two replicas draining 250 queued events concurrently reach zero, with every event republished exactly once
• Build, vet, and the component render all pass on the rebased branch
• After release, the production backlog drains from 420 and the stream reports a live consumer

Fixes #216
Related to #241

[ecv]

Production reports 420 dead-lettered events and zero consumers on that stream, so nothing has attached since this was filed and nobody has drained it by hand.

Two choices worth a second look.

The policy-triggered path scans rather than filters. One shared consumer carries one fixed subject filter, so that path cannot ask the server for its own subject any more and has to match client-side against whatever sits at the head of the queue. A single batch is useless there: with 120 other-policy events queued ahead and a batch size of 100, it processes 100 and republishes none of its own. Production is at 420 against that same batch size. It now scans until its own events run out, the context is cancelled, or 30 seconds pass, and defers a skipped event past the end of the scan so the loop cannot re-fetch what it just passed over.

The durable's pending-ack ceiling is twice the batch size because two replicas share the consumer. At one batch's worth, one replica can hold every slot while the other reads its empty fetch as a drained queue and ends its run early.