packs: single-registration deploy for zero-downtime canary rolls

[pipozzz]

Problem

Nomad-Pack deploys did two Nomad registrations per deploy:

1. nomad-pack run registers the pack as a Nomad-native service (invisible to Traefik's consulCatalog), then
2. a post-deploy patch re-registers it to Consul with the Traefik tags.

With a canary update stanza, each registration is its own canary transition. During the churn Traefik drops a service that momentarily has no passing instance (the count=1 cutover window) → a 404 window on every pack canary roll (observed live on goliash: ~90s of 404). This is why canary works for the panel/compose apps (single, canary-aware registration) but not for packs.

Fix — one clean registration

The deploy shell now renders only (nomad-pack render --to-dir). The panel then, in one pass:

• parses each rendered job (/v1/jobs/parse),
• re-stamps the pack.* meta so nomad-pack destroy and getPackJobIds still match,
• folds in ingress (provider=consul, Traefik tags, canary_tags = dark-until-promoted, shutdown_delay = graceful drain) and scaling (count/resources/autoscaling),
• registers the job once, then waits for the rollout (shared waitForRollout poller).

One registration = one canary transition, with canary_tags keeping the old alloc serving until the new one is healthy + promoted. Same mechanism the panel job already uses.

Changes

• builders/nomad.ts — getBuildNomadPackCommand renders instead of runs; add packRenderDir.
• setup/pack-nomad.ts — nomadParseHCL, registerRenderedPackJobs (parse + meta re-stamp + patch + register).
• setup/pack-domains.ts — buildPackJobPatch; canary_tags + shutdown_delay on patched services.
• setup/deploy-monitor.ts — extract/reuse waitForRollout (shared with the detached-nomad path).
• services/compose.ts — deploy + rebuild call registerPackDeployment; drop the old re-patch.
• test — assert the render command shape.

Scope / follow-up

startCompose (start-after-stop) still uses the old pattern — but it's start-from-stopped (no running service to keep up), so the canary/404 concern doesn't apply. Optional to unify later.

Validation

• scripts/check.sh passes: server prod build ok, 529 tests (incl. 2 new), app-tsc unchanged (8 pre-existing informational errors).
• nomad-pack destroy teardown unchanged (meta re-stamped).
• Not yet live-tested — recommend merging, rolling, then one goliash redeploy watched end-to-end (expect domain stays 200 throughout).

🤖 Generated with Claude Code