Task: Make the durable consumers durable

(Describe what user-visible-or-internal change this task produces.)

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The durable push consumers are durable now. They are created explicitly with a name, a delivery subject and a delivery group derived from the stream and the service, and the subscription binds to that consumer instead of creating one of its own. The server keeps the consumer and its position across a restart, so a command published while the service is down waits for it.

The acceptance was the reproduction that failed before. With ores.compute.service stopped, its consumer still existed and reported no interest, where before it disappeared. A command published into that window left one unprocessed message on the stream and none in flight. Starting the service delivered and acked it: ack floor one, unprocessed zero, redelivered zero, and the stream drained.

A full provisioning pass then completed tenant_setup_workflow nine steps of nine and nineteen bundle publishes, with all fifteen step-command streams drained to zero messages and one acked consumer each. Two consumers predating the restart were reused with their original creation time, which exercises the reuse path. The suites are 96 of 96.

Not covered, and worth its own task: the down-window delivery has no automated test, and MaxDeliver is ten with the default thirty second wait, so a service down for more than a few minutes could exhaust delivery attempts for a held command. The stream keeps the message for a day, but the delivery bound governs push redelivery.