Task: Check that every durable subject has its stream

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

A static check now applies the server's own two rules to every declaration it can read: every durably consumed subject is covered by exactly one stream filter, and no two differently named streams overlap. It reads the three declaration shapes the transport offers, resolves subjects through constants, and fails closed on a shape it does not recognise or on a new transport call, so silence is only ever possible for a file it never sees.

Shown failing before being accepted. A raw durable subscribe on an uncovered subject produced "durable subject with no stream", naming the site and explaining the five second timeout. A second stream over an existing filter produced "stream subject overlap", naming both streams and both sites and the server error the second would hit. Both reverts restored the tree to green.

On the tree it reports 19 streams, 17 durable consumers and 87 subjects, and the stream count matches the number independently recorded when the streams were investigated, which is evidence the extraction is faithful rather than merely self-consistent.

The honest limit, stated rather than papered over: a stale stream already on the broker cannot be seen statically. That was the actual cause of the overlap that stopped IAM starting, and only the owning service's ensure_stream catches it, as a fatal start. A service calling the cnats API directly is likewise outside the check's reach.