[Feature] Add transactional multi-node deployment and rollback

[data-angel]

Part of #9.

Problem

The current Spark deployment path updates one host at a time. It does not provide a cluster-level transaction that proves every required node is staged on the same artifact, orders gateway restarts, runs a distributed canary, and rolls the cluster back coherently.

Gateway-only releases may also restart an otherwise healthy model runtime when no runtime contract changed.

Proposed solution

Add a coordinated multi-node release workflow that:

1. Preflights required nodes, service persistence, credentials, config compatibility, and current workload.
2. Stages and verifies one immutable artifact and manifest on every target node.
3. Restarts node gateways in a safe order while preserving healthy inference where possible.
4. Restarts a runtime only when its effective runtime contract changed.
5. Runs cluster health checks and a real gateway inference canary.
6. Promotes all nodes together or rolls affected nodes back to their recorded prior artifacts.

Acceptance criteria

• Artifact and effective configuration digests are recorded per node.
• Partial staging or restart failure leaves the previous serving path recoverable.
• Gateway-only deployment does not restart unchanged inference containers.
• Canary verifies the public LLooM gateway model ID and selected runtime attribution.
• Rollback is exercised in automated failure-injection coverage.
• Human-readable and --json receipts identify staged, active, promoted, and rolled-back nodes.

Non-goals

• Multiple independent lifecycle leaders.
• Deploying unreviewed configuration or model weights.

[data-angel]

A live two-node recipe upgrade validated this tracker. The rollout exposed and fixed four prerequisite correctness gaps: placement preservation (#18), single-owner reload/keep-warm (#19), managed-container spec recovery (#20), selected-member node count/ranks (#21), and config-reload preemption (#22). All are now closed with regression coverage. The remaining #11 scope is still important: one cluster-level command should stage one artifact, apply node-local config in safe order, wait for distributed health, run canaries, and roll back automatically. No private hostnames, addresses, credentials, request content, or application identity are included here.