fix(docs,workflow): address round-2 deploy-via-tailscale review

- workflow: add `packages: read` to the job permissions so the
  `Verify image exists on ghcr.io` step's `docker manifest inspect`
  call works against private ghcr.io images (Codex P1).
- runbook §1: explain that `--ssh=false` disables Tailscale SSH and
  the workflow relies on the system sshd — operators who use
  Tailscale SSH elsewhere need to keep that in mind (Gemini Medium).
- runbook §4: change `ssh-keyscan` example + troubleshooting to
  `ssh-keyscan -H` so known_hosts entries are hashed and the secret
  does not leak tailnet topology in plaintext (Gemini Security
  Medium).
- runbook §4 variables: document that `NODES_RAFT_MAP` /
  `SSH_TARGETS_MAP` are workflow-side names the render step maps to
  the script's `NODES` / `SSH_TARGETS`; manual invocation from a
  workstation must use the script-side names (Gemini Medium).

Not addressed: Gemini HIGH claim that the workflow file is missing
(line 187) — it IS included at `.github/workflows/rolling-update.yml`
in this PR; the reviewer misread the file list.

Not addressed: Gemini HIGH re native --dry-run flag + zero-downtime
strategy (line 128) — dry-run is deliberately a workflow-level
input, not a script-level flag, so the script stays invokable from
a workstation without CI-specific options; zero-downtime cutover is
outside the scope of a CI wrapper and is tracked in the
resilience-roadmap follow-ups.

Author: bootjp

.github/workflows/rolling-update.yml

@@ -30,6 +30,7 @@ on:
 permissions:
   contents: read
   id-token: write   # required by tailscale/github-action OIDC flow
+  packages: read    # required by `docker manifest inspect` on ghcr.io private images
 
 concurrency:
   group: rolling-update

docs/deploy_via_tailscale_runbook.md

@@ -17,6 +17,13 @@ sudo tailscale up \
   --accept-routes=false
 ```
 
+`--ssh=false` disables Tailscale SSH, so the node's regular system
+sshd must be running and authorised to accept connections on the
+tailnet interface. The workflow uses plain SSH over the tailnet
+(Tailscale is only the network layer); if you rely on Tailscale SSH
+for operator access elsewhere, drop this flag but keep in mind the
+workflow still connects to the system sshd.
+
 Verify the node is reachable by MagicDNS from another tailnet peer:
 
 ```
@@ -75,7 +82,7 @@ friction for previews).
 | `TS_OAUTH_CLIENT_ID`        | Tailscale OAuth client ID from step 3 |
 | `TS_OAUTH_SECRET`           | Tailscale OAuth secret from step 3 |
 | `DEPLOY_SSH_PRIVATE_KEY`    | OpenSSH private key, authorized on every node under the deploy user |
-| `DEPLOY_KNOWN_HOSTS`        | `ssh-keyscan kv01.<tailnet>.ts.net kv02.<tailnet>.ts.net …` output (one host per line) |
+| `DEPLOY_KNOWN_HOSTS`        | `ssh-keyscan -H kv01.<tailnet>.ts.net kv02.<tailnet>.ts.net …` output. Use `-H` to hash hostnames so the secret's contents don't leak the tailnet topology if the runner environment is compromised. |
 
 The SSH key should be ed25519, dedicated to CI (not a reused developer key).
 Regenerate on operator rotation.
@@ -86,8 +93,15 @@ Regenerate on operator rotation.
 |------|-------|---------|
 | `IMAGE_BASE`      | Container image path (no tag)     | `ghcr.io/bootjp/elastickv` |
 | `SSH_USER`        | SSH login on every node           | `bootjp` |
-| `NODES_RAFT_MAP`  | Comma-separated `raftId=host` (no port — the script appends `RAFT_PORT`) | `n1=kv01,n2=kv02,n3=kv03,n4=kv04,n5=kv05` |
-| `SSH_TARGETS_MAP` | Comma-separated `raftId=ssh-host` | `n1=kv01.<tailnet>.ts.net,n2=kv02.<tailnet>.ts.net,...` |
+| `NODES_RAFT_MAP`  | Comma-separated `raftId=host` (no port — the script appends `RAFT_PORT`). The workflow renders this into the script's `NODES` env var. | `n1=kv01,n2=kv02,n3=kv03,n4=kv04,n5=kv05` |
+| `SSH_TARGETS_MAP` | Comma-separated `raftId=ssh-host`. The workflow renders this into the script's `SSH_TARGETS` env var. | `n1=kv01.<tailnet>.ts.net,n2=kv02.<tailnet>.ts.net,...` |
+
+**Why two names?** The workflow uses `NODES_RAFT_MAP` / `SSH_TARGETS_MAP`
+in the `production` environment to keep the GitHub-side names
+distinct from the script-side env var names it hands to
+`rolling-update.sh`. If you run the script by hand from a workstation
+you must export `NODES` and `SSH_TARGETS` directly — the workflow-side
+names are only understood by the workflow's render step.
 
 ## 5. Running a deploy
 
@@ -149,5 +163,5 @@ the tag is a moving tag (`latest`) that the verification step can't
 distinguish from stale. Specify an immutable tag.
 
 ### SSH `Host key verification failed`
-`DEPLOY_KNOWN_HOSTS` is stale. Re-run `ssh-keyscan` against every node and
+`DEPLOY_KNOWN_HOSTS` is stale. Re-run `ssh-keyscan -H` against every node and
 update the secret.