Serialize concurrent apply operations across planning and convergence checks #16

Audit finding

dpm apply currently plans from one snapshot, executes the emitted statements, and then re-introspects for convergence without a database-wide migration lock spanning that full window. Two deployers targeting the same database can therefore race: each may plan from stale state, interleave DDL, or misattribute residual drift.

Proposed work

• Define a deterministic lock identity per target database/schema set.
• Add a PostgreSQL implementation using a session-level advisory lock held across planning, apply, and final convergence verification.
• Design a CockroachDB-safe equivalent, likely a lease row with transactional compare-and-set semantics and expiry rather than PostgreSQL advisory-lock compatibility assumptions.
• Add configurable lock acquisition timeout and actionable diagnostics.
• Ensure the lock is released on success, error, cancellation, and process termination where the backend permits it.
• Add live stress tests with two concurrent dpm apply processes against PostgreSQL and CockroachDB.
• Document behavior for read-only diff/verify commands and multi-schema targets.

Acceptance criteria

• Concurrent applies against one target cannot execute migration statements concurrently.
• A timed-out contender exits non-zero without changing the target.
• PostgreSQL and CockroachDB live tests cover lock acquisition, timeout, owner failure, and subsequent recovery.

Discovered during the hardening work in #15.