Task: Implement A write checks the version of another party's row

Scope the current-row reads of a generated refdata service's write to the acting party, so the claim is checked against the row the write replaces.

Diagnosis: prepare_change in the service template reads read_one(repo_, ctx_, key_from(out)), keyed by the model's key (id). Under row-level security a parent party sees its subsidiaries, so the read returns several rows and current.front() is any of them. stamp() then sets party_id from the context, so the write lands on the acting party's row, which the check never looked at.

1. Add of_acting_party() beside stamp() in handler_helpers.hpp: keep the rows whose party_id is the context's party; a type with no party_id, or a context with no party, keeps every row.
2. Use it in the template's entity half: the claim check in prepare_change, the read-back of a put and a put many, and changed_columns. The junction half is left alone, because there party_id names the association's target.
3. Tangle the templates, regenerate the services, build, run the service suites.
4. Prove it live: the convention edit from the Acme login party lands, and a stale version is a conflict.

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.

• Root cause. prepare_change read the current row by the model's key, which for a convention is its id. Under row-level security a parent party's session sees its subsidiaries' rows of that id, so current.front() was any party's row, and the claim was checked against it. stamp() then set the acting party, so the write landed on a row the check never read.
• Fix. of_acting_party() beside stamp() keeps the context party's rows; a type with no party_id, or a context with no party, keeps every row, and a row with no party is kept. The template's entity half uses it; the junction half does not, because there party_id names the target.
• Left. A delete and an unclaimed write read by key too; see the capture Scope a delete and an unclaimed write to the acting party.

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.

• From the Acme login party, a convention edit lands against the version it read, and a stale version is still a conflict; other parties' rows of the same id are untouched.
• A put's reply carries the acting party's row.
• The build passes; the handler helper suite passes, with four new cases for of_acting_party().