Serialize Placement Changes and Rebuild Before Commit

Context

Descendant reads and officer visibility depend on ancestry matching current parent references. Concurrent opposing moves must not validate against the same stale arrangement.

Decision

The implemented placement flow uses a workspace tree lock and one transaction for validation, parent periods and rebuilding. Closure changes standing and deletion cleans up a removable unit without performing a whole-tree rebuild.

Alternatives Considered

Maintain only affected ancestry rows under fine-grained locks. Incremental maintenance would need a separate correctness argument for competing moves; the current implementation rebuilds from authoritative parents. Refresh ancestry after the parent transaction commits. Derived reads and subsequent validation could observe a parent arrangement that the old ancestry does not describe.

Consequences

Ordinary placement edits commit reconciled ancestry and depth; bulk loads defer that reconciliation. Structural edits wait behind one workspace lock, so tree size affects latency and throughput. Rebuild statements write differences rather than replacing every ancestry row.