feat(install): read-only deploy token for the private package registry (v0.1.2)

The GitLab project is private (its parent groups are private, so it cannot be
made public): the v0.1.1 one-liner answered 401 anonymously. install.sh gains
--token / MONKY_DEPLOYD_TOKEN and sends `DEPLOY-TOKEN: <token>` (a GitLab deploy
token, scope read_package_registry only, revocable) on every registry download,
the script itself included; the token goes through a 0600 curl -K file (never the
command line, the log or an xtrace). The grant is taken via --bootstrap-file when
the script is piped (stdin IS the script). Ansible: monky_deployd_download_token
(vaulted) -> DEPLOY-TOKEN header, no_log. Docs explain why, the token's scope and
the --source gitea alternative (split-horizon Gitea, cbs/iac#102).

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KLB7jieMNRkTsJ2epr4Ds1

README.md

@@ -18,12 +18,14 @@ Verified on **Ubuntu 26.04**.
 ## Install (one-liner, from the enrolment kit)
 
 An admin reveals the kit once in the console (`GET /v1/backends/{id}/agent/install`); it hands
-you the enrolment JWT and a one-time **bootstrap deploy grant**. On the box:
+you the enrolment JWT, a one-time **bootstrap deploy grant** and the read-only **download token**
+(the kit runs the line below for you). By hand, on the box:
 
 ```sh
-curl -fsSL https://scm.tikali.ai/tikali/applications/monky/monky-deployd/-/raw/main/packaging/install.sh \
-  | sudo bash -s -- --env env-qa-02 --site cbs --enrol-jwt ./monky-host.env-qa-02.jwt < bootstrap.jwt
-#   [--transport sdk|proxy|system] [--version 0.1.1] [--laptop] [--bao-ca openbao-ca.pem] [--source gitlab|gitea]
+T=<deploy token>   # read-only GitLab deploy token (read_package_registry); the kit carries it
+curl -sSf -H "DEPLOY-TOKEN: $T" https://scm.tikali.ai/api/v4/projects/69/packages/generic/monky-deployd/0.1.2/install.sh \
+  | sudo bash -s -- --env env-qa-02 --site cbs --token "$T" --bootstrap-file bootstrap.jwt --enrol-jwt ./monky-host.env-qa-02.jwt
+#   [--transport sdk|proxy|system] [--version 0.1.2] [--laptop] [--bao-ca openbao-ca.pem] [--source gitlab|gitea]
 ```
 
 `install.sh` installs `ziti-edge-tunnel` (OpenZiti `jammy` suite) and `docker-compose-plugin` if
@@ -32,11 +34,21 @@ absent, downloads the pinned `.deb` + `.sha256` from the [scm.tikali.ai generic
 enrols `monky-host.<env>` if the identity is missing, switches the tunneler to `run-host`,
 writes `/etc/monky-deployd/config.yaml`, grants the agent read access to the identity (ACL),
 stages the bootstrap grant (0600), enables `monky-deployd.timer`, runs one tick and deletes the
-JWT. The GitLab project is **public**, so anonymous downloads work from scm.tikali.ai. Why not the
-Gitea mirror: inside the estate `gitea.cbs.tikali.net` is split-horizon to jump1's RED EIP
-(`10.10.0.175`), which has no HTTP ingress, so backend boxes cannot reach it (cbs/iac#102);
-`--source gitea` (or `MONKY_DEPLOYD_SOURCE=gitea`) keeps the
-[Gitea release](https://gitea.cbs.tikali.net/mdella/monky-deployd/releases) as the off-estate alternative.
+JWT.
+
+**Why a token.** The GitLab project is **private** and cannot be made public (its parent groups
+are private), so anonymous downloads answer 401. Every registry fetch — the script itself
+included — therefore sends `DEPLOY-TOKEN: <token>`: a GitLab **deploy token** with the single
+scope `read_package_registry` (it can download packages and nothing else: no code, no API, no
+write; revoke it in the project's *Settings → Repository → Deploy tokens* and issue a new one).
+The operator seeds it in OpenBao at `monky/monky-tenancy/deployd-download` (key `token`); the
+monky-tenancy install kit reads it from there and passes `--token` (`MONKY_DEPLOYD_TOKEN` also
+works). The script never prints it (curl `-K` config file, 0600, deleted after the download;
+`set -x` is switched off). Why not the Gitea mirror: inside the estate `gitea.cbs.tikali.net` is
+split-horizon to jump1's RED EIP (`10.10.0.175`), which has no HTTP ingress, so backend boxes
+cannot reach it (cbs/iac#102); `--source gitea` (or `MONKY_DEPLOYD_SOURCE=gitea`, no token) keeps
+the [Gitea release](https://gitea.cbs.tikali.net/mdella/monky-deployd/releases) as the
+off-estate alternative.
 
 ## Transports
 
@@ -145,8 +157,8 @@ systemd-analyze verify packaging/systemd/*.service   # where systemd is availabl
 egress to github.com and pypi.org) and `package` builds the `.deb` with `nfpm` (binary from GitHub
 releases, goreleaser apt repo as fallback). Both were proven on the v0.1.0 tag pipeline and are
 blocking on `main`/tags (manual on MRs); the `.deb` always ships the SDK wheel. On a `v*` tag
-`release` uploads to the GitLab generic package registry + release (**the primary download**, public
-project), and `release:gitea` publishes the same assets on the Gitea mirror (the `--source gitea`
+`release` uploads to the GitLab generic package registry + release (**the primary download**; the
+project is private, so the installer sends the read-only deploy token), and `release:gitea` publishes the same assets on the Gitea mirror (the `--source gitea`
 alternative; automatic when `GITEA_TOKEN` is set, manual otherwise — see `docs/OPERATIONS.md` for
 the by-hand recipe). Both locations keep being published.