Fix: Resolve grafting bugs

[dimitrovmaksim]

Resolves #6220, resolves #6221

Issue: #6220

Currently, the can_copy_from validation is only performed when a deployment is considered new—that is, when no existing deployment_schema record exists for the given Qm hash.

In the code here, the layout is assigned if the deployment is new. If a deployment_schema record already exists, the code assumes the deployment was previously created and copied successfully, and therefore sets graft_base_layout to None.

However, if can_copy_from later fails (see here), the transaction rolls back all changes except the record in the deployment_schemas table. This leaves the deployment in a partially created state and copy was never attempted

When the same deployment is attempted again, it is no longer treated as new. As a result, graft_base_layout is set to None, and the can_copy_from check is skipped. The deployment then proceeds as if it were valid, the copy process starts, but it fails again—ultimately leaving the deployment stuck in a "never synced" state.

What this PR changes:

Move the can_copy_from check and the site allocation in a transaction so a failing check fully rolls back the allocation.

Remove the duplicate/late compatibility check from deployment_store.rs

Use Catalog + Layout::new(...) to construct the layout and run layout.can_copy_from(&base_layout) before committing.

Minor cleanups (string formatting improvements, unused variables removed).

Removed the can_copy_from check from copy_deployment because it passed the source layout as the graft base and then compared it against the destination layout, which seems as a redundant check since the two layouts are the same.

Result

Now every re-deploy of a failed deployment should behave as a brand new deployment, and the if !exists check should behave correctly.

Note: This approach may result in deployment_schemas_id_seq gaps