Task: Edit a row only in its owning party

A person who sees a child party's engine settings from the group party reads the record and its history, and edits only after switching to the owning party.

• The record page of another party's row is read-only and names the owning party, with a button that switches to it.
• A write from the wrong party answers with a refusal that names the owning party, and never a repository error.

(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 BFF refuses the history, the rename, the delete and a group save of a configuration that another party owns. The answer is a 409 with the code other-party and the name of the owner, in place of a not-found or a repository error. The record page reads the owner from the record. When it is not the party the session acts in, the page draws a notice that names the owner, offers a button that switches to it, removes Edit and Delete, and says that the history is in the owning party. A test in the BFF and in the web client covers each.