docs(deploy): round-5 deploy-via-tailscale review fixes

- Gemini Medium (design §2.6 line 146): the design doc contradicted
  the runbook by claiming dry-runs do NOT need approval. GitHub's
  environment-protection rules cannot be made conditional on workflow
  inputs, so `environment: production` pauses BOTH dry-run and
  non-dry-run executions in v1. Aligned the design-doc wording with
  the runbook and cross-referenced §4 for the second-environment
  upgrade path.
- Gemini Medium (runbook §6 line 164 env list): the list of
  reconstruction vars was incomplete. Listed every env var the
  workflow actually exports (IMAGE, DATA_DIR, RAFT_PORT, REDIS_PORT,
  S3_PORT, ENABLE_S3, NODES, SSH_TARGETS, EXTRA_ENV) and called out
  the script-level defaults for anything not overridden, plus noted
  GOMEMLIMIT / CONTAINER_MEMORY_LIMIT are propagated via EXTRA_ENV
  once PR #617 lands.
- Gemini Medium (runbook §6 line 178 idempotency): corrected the
  "stop+recreate every node regardless" claim. The script
  (scripts/rolling-update.sh:794-798) skips nodes whose running
  image id matches the target AND whose gRPC endpoint is healthy,
  so re-running after a partial roll is safe because already-rolled
  nodes are no-ops, not stops.

Declining again Gemini HIGH "workflow file missing" — the file IS
in this PR at .github/workflows/rolling-update.yml; this is the
fourth round the bot has flagged its own misread. See prior rounds
for rationale; no change.

Author: bootjp

docs/deploy_via_tailscale_runbook.md

@@ -158,12 +158,19 @@ hazard that needs manual cleanup.
 2. **SSH into that node** over Tailscale and run `docker ps`. If the
    container is absent or `Exited`, finish the recreate by hand. The
    `docker run` invocation itself is redirected to `/dev/null` by the
-   script, so the workflow log does NOT contain the full argv. Use
-   the resolved env instead: the step logs `NODES_RAFT_MAP`,
-   `EXTRA_ENV`, `GOMEMLIMIT`, `CONTAINER_MEMORY_LIMIT`, `IMAGE`, and
-   `DATA_DIR` before invoking the script — those are sufficient to
-   reconstruct the same `docker run` you would see if you re-ran with
-   the same inputs.
+   script, so the workflow log does NOT contain the full argv. To
+   reconstruct it, read the `Roll cluster` step's rendered
+   environment — the workflow exports `IMAGE`, `DATA_DIR`,
+   `RAFT_PORT`, `REDIS_PORT`, `S3_PORT`, `ENABLE_S3`, `NODES`,
+   `SSH_TARGETS`, and the merged `EXTRA_ENV` before invoking the
+   script. Anything not explicitly set (e.g., `RAFT_PORT` in a
+   minimally-overridden deploy) falls back to the script's default
+   (`RAFT_PORT=50051`, `REDIS_PORT=6379`, `S3_PORT=9000`,
+   `ENABLE_S3=true`). GOMEMLIMIT / CONTAINER_MEMORY_LIMIT (PR #617)
+   are propagated via `EXTRA_ENV` once that PR lands. Together the
+   rendered env + the node's `deploy.env` is enough to reconstruct
+   the same `docker run` you would see if you re-ran with the same
+   inputs.
 3. **Confirm the new leader via `raftadmin` or metrics** before re-running
    the workflow with `nodes:` scoped to the remaining untouched IDs. Do
    NOT re-run the full rollout if the partial one is still in flight —
@@ -172,10 +179,13 @@ hazard that needs manual cleanup.
    workflow to set a start-marker on each node and fast-skip completed
    nodes on re-run.
 
-The script is idempotent for the "container exists and is up" case, so
-re-running the workflow with the same `ref` after confirming the
-interrupted node is healthy is safe — the script will stop+recreate
-each node in turn regardless of whether it was touched before.
+The script is idempotent. `scripts/rolling-update.sh:794-798` skips a
+node when its running image id equals the target image and its gRPC
+endpoint is healthy — an already-rolled node is a no-op, not a
+redundant stop/recreate. Re-running the workflow with the same
+`ref` after confirming the interrupted node is healthy is therefore
+safe: nodes that already match the target image are passed over,
+and only the still-stale one gets recreated.
 
 ## 7. What the workflow does NOT do (yet)
 

docs/design/2026_04_24_proposed_deploy_via_tailscale.md

@@ -141,15 +141,21 @@ unreachable over the tailnet) before touching any live container.
 
 ### 2.6 Production environment approval
 
-Mark the `production` GitHub environment as requiring approval from a list of
-reviewers. A non-dry-run deploy will pause until approved; the dry-run run
-itself does not need approval (it only needs the tailnet join).
+Mark the `production` GitHub environment as requiring approval from a list
+of reviewers. GitHub's native environment-protection rules do NOT support
+conditioning approval on workflow inputs, so **both** dry-run and non-
+dry-run runs will pause for approval when `environment: production` is
+declared unconditionally on the job. That is the v1 policy — simpler,
+one environment, one approver list; see runbook §4 for the dry-run-
+approval alternatives (a second `production-dry-run` environment without
+required reviewers, or a deployment-protection-rule GitHub App).
 
 Alternative: require approval unconditionally and treat the dry-run as a
-"preview" that an approver must ack. Simpler policy, slightly more friction.
+"preview" that an approver must ack. This is the v1 shape by default.
 
-**Recommendation:** approval required for non-dry-run only. Dry-runs are
-cheap and useful.
+**Recommendation:** approval required for every run in v1 (one
+environment). Add the second environment only when the dry-run friction
+becomes annoying.
 
 ### 2.7 Rollback