deploy: report skipped setup steps after updates

[samadasyed]

Updating from a pre-guard update.sh can pull new code and report “Healthy” while skipping the sandbox configuration, silence-check units and bridge-token migration. The update now reports the web response separately from installed deployment configuration. Missing files or unmigrated bridge-token assignments produce an actionable warning and a nonzero update result; the operator update command also checks after an old updater finishes.

The same read-only check is available through operator status and a separate login entry installed by setup/update. A deliberately disabled sandbox is valid, and diagnostics inspect assignment names without sourcing .env or displaying token values. Deployment docs explain when an older updater needs a second run.

Validation: all eleven CI checks passed at head 4e5bd50, including all 98 shell scripts and 38 regression assertions on both Linux and native macOS/Bash 3.2.57 (ARM64). An offline regression runs the historical updater from bbb11046352bae233024d287dcb8e4eb53b99a3b through a real local git pull, with system commands and HTTP stubbed. All 38 checks pass on Bash 5.2 and 3.2; unchanged main fails 30. Existing sandbox, migration, silence-alert and unit-name tests pass on both Bash versions. ShellCheck passes 173 files and Bash 3.2 parses 137 product scripts. The local full harness passed 95/98. Context and LLM tests passed isolated reruns; the linked-worktree runtime timestamp assertion also failed identically on unchanged main. The LLM cleanup failure also reproduced on unchanged main due to an unrelated shared temporary file; the one transient context failure had no established baseline cause.

Scope: terminal/status/login diagnostics and documentation. Dashboard reporting is deferred. Checks establish installed file presence, rather than running-dispatcher settings, timer activation or full credential isolation. No live deployment or service restart was performed.

[custos-1f916]

Reviewed at 4e5bd50.

Two-channel reporting is the right cut: the web health endpoint and the installed deployment configuration are different facts, and conflating them is exactly how "Healthy" masked skipped sandbox/silence/bridge steps. The check is read-only, never sources .env, and identifies bridge assignments by name only (grep -qE, no value captured) — the "commented credentials are ignored and never printed" test pins that.

set -uo pipefail (no -e) is deliberate and correct for a collect-and-report diagnostic: the grep ... ; rc=$? pattern needs -e off to read the exit code, and multiple warns accumulate into a single exit 1.

The re-exec gap is the subtle part and it's handled: an old updater can't re-exec a guard it only acquired in this pull, so deploy/scripts/update runs the newly pulled check-deploy.sh --warnings-only after the old updater finishes, and update.sh itself runs the check after web health. The --render-motd login entry uses %q path quoting (spaces/quotes/dollars covered by the test) and re-reads current config on each login.

Verified locally (hermetic, head 4e5bd50): tests/test_deploy_update.sh → 38 passed, 0 failed, exit 0. Ran the same test against the merge-base deploy code (PR's new test + fixture, unchanged main scripts) → 8 passed, 30 failed — matches the PR body's "unchanged main fails 30" exactly, so the suite is discriminating, not just green. CI green (run 36965818474).

Scope limits are stated honestly in DEPLOY.md (checks installed files, not running-dispatcher settings/timer activation/full credential isolation). LGTM.

[nickjalbert]

merging!