multica_agent_host: install the 1Password CLI from 1Password's signed repo (WDWL-37)

Agents get `op` so op:// references resolve at command time and secret
values stay out of prompts and transcripts. Installed per 1Password's
apt instructions (signed-by keyring, debsig policy + keyring,
1password-cli), with the key fingerprint-checked before it is trusted;
EL via their yum repo. multica_op_version pins, "" tracks the repo.
Tag: multica_op.

Optional, default-off hook writes OP_SERVICE_ACCOUNT_TOKEN from the
playbook (ansible-vault) to a 0600 file owned by the daemon user. It is
deliberately not wired into the daemon environment: the user unit
belongs to the multica CLI, and the delivery design is pending.

Rolled out with --tags multica_op to haunted-mansion and spaceship-earth;
second run changed=0, op 2.41.1 as multica, debsig verifies the .deb.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ansible/roles/multica_agent_host/README.md

@@ -37,6 +37,8 @@ otherwise clean at the `production` profile.
 | Node.js, pinned, from nodejs.org with SHASUMS256 verification | yes, when an npm-installed agent CLI is selected |
 | `multica` CLI, pinned, from the GitHub release with `checksums.txt` verification | yes |
 | Agent CLIs (`claude`, `hermes`, …) | yes |
+| 1Password CLI (`op`), from 1Password's signed apt/yum repository | yes (`multica_op_install`) |
+| 1Password service account token, as a 0600 file for the daemon user | opt-in (`multica_op_deliver_token`); not exported to the daemon |
 | `workspaces_root`, on the intended mount, writable by the daemon user | yes |
 | Multica authentication (`multica login --token`) | yes |
 | CLI config (`server_url`, `app_url`, `workspaces_root`, `device_name`, …) | yes |
@@ -236,6 +238,9 @@ See `defaults/main.yml` for the annotated list. The ones you will actually set:
 | `multica_user` | `multica` | Daemon service account. |
 | `multica_profile` | `""` | `--profile`, to isolate config/daemon state/workspaces. |
 | `multica_allow_remote_install_scripts` | `false` | Required for `hermes`; see below. |
+| `multica_op_install` | `true` | 1Password CLI from 1Password's apt/yum repo. |
+| `multica_op_version` | `""` | `""` tracks the repo (upgrades on every run); set e.g. `2.41.1` to pin. |
+| `multica_op_deliver_token` | `false` | Write `multica_op_service_account_token` to `multica_op_token_file`. |
 
 ### Adding an agent CLI
 
@@ -366,6 +371,58 @@ ssh -t scratch-vm 'sudo -iu multica claude'
 That step only becomes automatable if the host moves from a subscription to an
 API key.
 
+## 1Password CLI
+
+`op` lets an agent resolve `op://vault/item/field` references at the moment
+it runs a command (`op run -- cmd`, `op inject -i tpl -o out`, `op read`), so
+the secret value never has to appear in a prompt, an issue or a transcript.
+The 1Password desktop-app integration (and the Claude Code plugin built on it)
+needs a GUI session, so headless agent hosts use a **service account** instead.
+
+Install, Debian/Ubuntu, exactly as 1Password documents it, with one addition:
+
+- the key at `multica_op_key_url` is fingerprint-checked against
+  `multica_op_key_fingerprint` before it is dearmored, so apt never trusts a
+  substituted key;
+- dearmored to `/usr/share/keyrings/1password-archive-keyring.gpg` (apt,
+  `signed-by=`) and to `/usr/share/debsig/keyrings/AC2D62742012EA22/debsig.gpg`
+  with the policy in `/etc/debsig/policies/AC2D62742012EA22/` (debsig-verify);
+- `1password-cli` from `downloads.1password.com/linux/debian/<arch> stable`.
+
+EL uses 1Password's yum repository with `gpgcheck` and `repo_gpgcheck`.
+The play then runs `op --version` as the daemon user, in the daemon user's
+environment.
+
+### The service account token
+
+The role can deliver the token, but by default does not:
+
+```yaml
+multica_op_deliver_token: true
+multica_op_service_account_token: "{{ vault_op_service_account_tokens[inventory_hostname_short] }}"
+```
+
+writes it to `multica_op_token_file`
+(`~multica/.config/op-service-account/token`, directory 0700, file 0600,
+owned by the daemon user). That is all it does. **The role does not put the
+token into the daemon's environment**, for two reasons:
+
+1. The daemon's systemd user unit is written and owned by the multica CLI
+   (`multica daemon autostart`). The role must not template or edit it, or it
+   silently freezes the CLI's `ExecStart`, environment and restart semantics.
+2. Anything in the daemon's environment is inherited by every agent process
+   it spawns, where a casual `env` or `printenv` puts it in a transcript.
+
+How the token reaches `op` is a separate decision, not yet made. Until then
+an agent can use it explicitly:
+
+```bash
+OP_SERVICE_ACCOUNT_TOKEN="$(cat ~/.config/op-service-account/token)" op run -- <cmd>
+```
+
+`op` reads the token only from `OP_SERVICE_ACCOUNT_TOKEN`; it has no
+token-file option.
+
 ## Known gaps
 
 - **Provider CLI login.** Unavoidable for subscription auth.
@@ -387,6 +444,7 @@ API key.
 | `multica_auth` | `multica login` |
 | `multica_daemon` | autostart + start |
 | `multica_verify` | the assertions |
+| `multica_op` | 1Password CLI, and the token file when enabled |
 | `multica` | all of the above |
 
 Preflight and the service-account step are tagged `always`: they build