hardening: review native deploy start lock order

Context

PR #269 closes the hot-path pieces of #211:

• supersede and multi-row batches now use deterministic id ASC lock acquisition
• job completion has a cheap precheck before the authoritative CAS
• terminal run effects are durable and generation-fenced
• FinalizeDeployWatch now uses a fence-last protocol so the deploy watch is the final ownership check

One low-risk sliver remains from the global deploy-table lock-order bullet: the native deploy start path.

Follow-up

Review and, if needed, align StartNativeDeploy / StartNativeDeployDeclared with the documented global order around:

Lane -> Pipeline -> Freeze -> deploy_target -> run -> stage -> job -> artifact -> deployment_revision -> deploy_watch

The declared path already takes the freeze/advisory check before the deploy-target lock, and creates deployment_revision before deploy_watch. The remaining question is whether the job/stage/run portion of startNativeDeployTx should be reordered to match the exact global sequence without changing dispatch semantics.

Guardrails

• Preserve the existing behavior: a started native deploy must still atomically create the revision/watch and leave the server-managed job running.
• Do not hold DB locks across external Sync I/O.
• Keep the lost-dispatch CAS behavior (Started=false) unchanged.
• Add a concurrency regression if any lock order changes.

This is intentionally separate from #211/PR #269 because the terminalizer path was the hot cross-order risk; this start path is creation-side and lower contention.

Start by inspecting StartNativeDeploy, StartNativeDeployDeclared, and startNativeDeployTx, then compare their lock acquisition with the documented global order and the behavior described in PR #269. Done means preserving dispatch semantics, atomic revision/watch creation, the lost-dispatch CAS, and the no-lock-across-Sync-I/O rule; add a concurrency regression if the order changes.