Task: Wire the captures into the backlog index

A capture this story files is findable in the backlog it belongs to.

• Both captures appear in the inbox table.
• The capture document states that compass add capture does not regenerate the index.

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

Both captures appear in the inbox. Before the index regeneration, grep found neither slug in inbox.org while both documents were on disk.

What caused it: compass add capture writes the capture document, and the bucket index is a separate artefact that regenerate_backlog_indexes.py writes. The tool's own help says so for compass capture --commit, but the generic compass add capture says only "remember to wire the new artefact into its parent", which reads as advice about the sprint table and not about the backlog index.

So the rule for the next capture: after compass add capture, run regenerate_backlog_indexes.py, or the capture is a document nothing lists.