Add API-controlled rollout control plane

[chrisbliss18]

Summary

Adds the API-driven rollout control plane needed for containerized v1-to-v2 migration where operators may not have shell access to the Monitor containers.

What changed

• Adds ROLLOUT_MODE with active, standby, and api-controlled so v2 Monitors can run safely without claiming buckets until explicitly activated through the API.
• Adds rollout API migrations for durable sessions, range locks, per-bucket locks, job records, hashed short-lived confirmation tokens, persisted method-comparison deltas, and staged policy rollback history.
• Adds admin-scoped rollout API endpoints for capabilities, sessions, preflight, read-only smoke checks, seed/adopt, final reconcile, activate/release, status, post-handoff gates, method comparison, and staged policy migration.
• Makes preflight validate schema version, API-controlled mode, delivery guards, configured v2 Veriflier contract support, quorum-counted vantage.id coverage, duplicate-vantage safety, and active-discovery registry entries with static fallback semantics.
• Runs sampled read-only HEAD + legacy smoke probes without writing incident state, runtime freshness, check history, WPCOM notifications, or legacy projection rows.
• Runs sampled non-authoritative HEAD/GET comparison probes and persists deltas in jetmon_rollout_comparison_results for rollout analysis.
• Executes staged policy changes through jetmon_site_check_config, requires explicit cohort size, records previous values in jetmon_rollout_policy_stage_rows, and supports pause, rollback-last-stage, and rollback-all modes.
• Seeds v2 side tables and adopts existing v1 non-running projections into v2 event state without sending duplicate down notifications.
• Expands jetmon2 api rollout guided with session creation, final reconcile, transcript logging, resume state, run/change references, rollback release flow, safer sample defaults, and primitive rollout commands.
• Adds execute-step idempotency keys to the guided rollout flow so operators can safely retry after a lost HTTP response.
• Binds confirmation tokens to the authenticated API key identity, not just the consumer name or typed phrase.
• Warns on empty smoke/comparison ranges instead of treating an empty sample as proof that a range is healthy.
• Blocks stale stage-policy execute attempts when the live plan has become blocked.
• Makes API-controlled Monitors poll durable bucket locks and return to standby when a lock is released, including the streaming scheduler path.
• Disables embedded delivery workers in standby and API-controlled rollout modes.
• Updates the rollout docs, API guide, data model, config reference, and roadmap to describe the new API-driven container rollout path.
• Consolidates the launch-critical prelaunch checklist and documents that synthetic canary tests are required before first production activation, even while API-native canary execution remains a follow-up.

Example operator flow

./jetmon2 api rollout guided \
  --bucket-min=0 \
  --bucket-max=99 \
  --change-ref=SYSREQ-12345 \
  --allow-remote

Rollback uses the same guided surface:

./jetmon2 api rollout guided \
  --bucket-min=0 \
  --bucket-max=99 \
  --rollback \
  --allow-remote

After v2 owns the fleet and is stable, optional comparison and policy migration gates can be included:

./jetmon2 api rollout guided \
  --bucket-min=0 \
  --bucket-max=99 \
  --include-comparison \
  --include-policy-migration \
  --allow-remote

Safety notes

• Mutating rollout endpoints require admin-scoped API keys.
• Activation requires ROLLOUT_MODE=api-controlled.
• Execute operations require confirmation tokens from matching dry-run plans.
• Confirmation tokens are hashed at rest and bound to operation, range, run ID, authenticated API key identity, and request shape.
• Guided execute requests include idempotency keys.
• Synchronous smoke and comparison probes default to 100 samples and reject more than 1000 samples per request.
• Stage-policy migration requires an explicit size so a missing flag cannot migrate the full eligible range.
• A single Monitor owner may only hold one contiguous API-controlled range.
• Synthetic canary execution remains tracked as a follow-up until production canary URLs and expected states are finalized, but the prelaunch docs now require those canary tests to be run through an approved external/manual path before first production activation.

Validation

• go test ./...
• make rollout-docs-verify
• git diff --check
• JETMON_API_CONFIG=off go run ./cmd/jetmon2 api rollout guided --bucket-min=0 --bucket-max=2 --dry-run --include-comparison --include-policy-migration
• JETMON_API_CONFIG=off go run ./cmd/jetmon2 api rollout guided --bucket-min=0 --bucket-max=2 --rollback --dry-run
• JETMON_API_CONFIG=off go run ./cmd/jetmon2 api commands --output table