Take aggregate locks before existence checks in create-vs-delete flows

When create-new-version and delete-final-draft share a PostgreSQL advisory lock, acquire that lock before checking the aggregate parent exists. Checking first allows creation to observe a parent that a concurrent delete later removes, then resume after the lock and fail with an unmapped FK error. The safe order is choose aggregate ID → advisory lock → existence check or parent insert → version allocation/write; regression-test it with two connections and assert a domain NOT_FOUND rather than raw 23503. Observed 2026-09-08T10:38:52Z from candidate-signal COR-4085 / PR #11 review, PostgreSQL CI, and production deployment.