Task: Ensure the streams a service reads

(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.

No change was needed. Every durable step consumer already ensures its stream at startup through serve_step_commands, before it subscribes, and the pattern was implemented on main after this story was captured.

Verified from an empty JetStream: all twenty streams were deleted, the database recreated, and the services alone recreated nineteen streams before provisioning ran. Provisioning then completed end to end, tenant setup nine steps of nine plus nineteen bundle publishes, with every step delivery acked, nothing pending and nothing redelivered. The step streams drained to zero messages, which is the proof each command was consumed rather than merely published.

The overlap that stopped the IAM service starting was a legacy store from before main split the step streams, not a defect in the current code.