spec: require multi-ref entities to write as one atomic proposal

Phase 9’s review entity occupies two refs (its own tree and a retention pin) that must both exist for the review to exist at all, but receive.adoc never said how such a pairing gets written. The gap let phase 9’s review new write the two refs as two independent, sequential proposals: if the second write fails, a review is left with no retention pin, silently losing model.review-pin’s reachability guarantee — exactly the failure mode the existing atomic multi-ref CAS (arch.refstore-read-cas-split) exists to prevent, had the spec required its use.

feat: add receive.multi-ref-atomicity, requiring every ref of a multi-ref entity to travel in one Proposal / one receive() call, distinguished from the inbox/canonical relationship’s deliberate two-time write Assisted-by: Claude:claude-sonnet-5