Task: Scaffold the synthetic implementation story

The story is wired into the sprint and its tasks are filed.

(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 story is filed and wired into Sprint 27, and its nine tasks are in dependency order. Nothing is built yet, and the ordering is the whole point of the scaffold: the screens cannot come first.

ores.web cannot speak the component. Seventeen components have a committed TypeScript protocol and synthetic is not one of them, because its nine models carry no * Physical space section: no address is declared, so there is nothing for the TypeScript facet to project. The BFF reaches the bus only through those generated modules, so a screen built now would have nothing to call.

The order is therefore the models onto the address mechanism, then the protocol twin, then the BFF routes, then the screens. The twin cannot be done for two entities at a time either: once generated/synthetic/protocol/ exists, check_protocol_twin_coverage.py demands a twin for every synthetic header.