feat(pm-agent): pin the first published agent-runner digest, start dry, and fix the token scopes

Rebased #61 onto the CI image pipeline (#81). This commit makes the remaining in-git
blockers to going live go away:

- deployment.yaml and PM_WORKER_IMAGE pin images run 340's digest (sha256:c4eba5b3...,
  tag sha-523cd9118f95 = main), read from the registry. Renovate markers unchanged.
- PM_DRY_RUN=true and PM_REQUIRE_LABEL=agent for the first run. Dry run is required, not
  just cautious: the run-340 image's baked worker template predates imagePullSecrets, so
  admission would deny its Jobs until CI re-publishes after this merge and Renovate bumps.
- Token scopes: Gitea 1.24.3 scopes GET /api/v1/user (the dispatcher's first call) under
  read:user. The documented list was missing it. Now read:user, write:repository,
  write:issue, read:package everywhere.
- Org-package read documented as a team (Packages=Read, no repos), not just a scope.
- sops is toolbox-only; the .examples say so and give the in-place edit.
- runbook: key-name check no longer emits Secret values before the pipe.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

platform/pm-agent/README.md

@@ -46,15 +46,17 @@ waive the sensitive-path human review on its own pull request.
 Both are deliberate, and both fail **visibly** rather than silently:
 
 1. **The image is published by CI, not by a person.** `platform/pm-agent/deployment.yaml` and
-   `PM_WORKER_IMAGE` in `configmap.yaml` carry an all-zero digest placeholder until the first
-   publish. `.gitea/workflows/images.yaml` builds `agent-runner` on rootless BuildKit
+   `PM_WORKER_IMAGE` in `configmap.yaml` carry the digest of the **first** publish (images
+   run 340, `sha-523cd9118f95`), pinned once on 2026-10-30 so going live did not wait on
+   Renovate's first run; every later bump is Renovate's. That digest predates the worker
+   template's `imagePullSecrets` entry, so worker Jobs built from it are refused by
+   admission — which is why `PM_DRY_RUN` starts `true` (see `configmap.yaml`). `.gitea/workflows/images.yaml` builds `agent-runner` on rootless BuildKit
    (`platform/buildkit/`) — the same Containerfile, and the same `verify` stage, that
    `infra/agent/build-image.sh` builds locally — and on a push to `main` publishes it to
    `gitea.home.keithjackson.dev/home-network/agent-runner` under `sha-<commit>` and `main`.
    Renovate then follows the `main` tag through the `# renovate-digest:` marker above **both**
    lines and moves them together in one pull request. Nobody builds-and-pushes this image from
-   a workstation, and nobody pastes a digest. Until the first publish, and until that PR
-   merges: `ImagePullBackOff`. The one operator prerequisite on the publishing side is the
+   a workstation. The one operator prerequisite on the publishing side is the
    `REGISTRY_PUSH_TOKEN` Actions secret (see the header of `.gitea/workflows/images.yaml`);
    without it the publish job fails loudly rather than skipping.
 
@@ -83,7 +85,7 @@ Both are deliberate, and both fail **visibly** rather than silently:
      `pm-agent-registry` is a `dockerconfigjson` Secret referenced by both the Deployment and
      the committed worker Job template, and the admission policy pins it to exactly that
      name. What is left to you is the value: the Gitea token must carry **`read:package`** in
-     addition to `write:repository` and `write:issue`, and the dockerconfigjson is built from
+     addition to `read:user`, `write:repository` and `write:issue`, and the dockerconfigjson is built from
      it. Steps:
      [`pm-agent-registry.sops.yaml.example`](./pm-agent-registry.sops.yaml.example).
 
@@ -99,8 +101,11 @@ Both are deliberate, and both fail **visibly** rather than silently:
 
    They hold the **same** Gitea token in two formats, because a Secret cannot be both — the
    same one-value-in-two-files pattern the Keycloak client secret already uses here. So mint
-   it once, with all three scopes: `read:package` (the pull), `write:repository` (clone,
-   branch push, pull request) and `write:issue` (issue comments). The first `.example`
+   it once, with all four scopes: `read:package` (the pull), `read:user` (the dispatcher's
+   startup `GET /user` — Gitea 1.24.3 scopes the whole `/user` group), `write:repository`
+   (clone, branch push, pull request) and `write:issue` (issue comments). The account also
+   needs package *permission*, not just the scope: a `pm-agent-pull` org team with Packages
+   = Read and no repositories (steps in the registry `.example`). The first `.example`
    explains which account to create and why it must *not* be an administrator.
 
    Until they are filled in: the pull fails `401`, and if you fix only the pull, the
@@ -174,7 +179,7 @@ Job from a committed template. **The model's output is data, never a command.**
 - **The worker's own credentials are inside the model's reach.** The session runs as the same
   uid in the same container as the wrapper, so it can read the environment, including its
   `GITEA_TOKEN` and `CLAUDE_CODE_OAUTH_TOKEN`. There is no isolation between them and none is
-  claimed. What bounds it: the Gitea token is scoped `write:repository, write:issue` on **one
+  claimed. What bounds it: the Gitea token is scoped `read:user, write:repository, write:issue, read:package` on **one
   repository** with no admin permission, and egress reaches only this Gitea and tcp/443.
 - **`world:443` is wider than `api.anthropic.com`.** Cilium can express the tighter rule
   (`toFQDNs`) but nothing in this repository uses FQDN policy and its prerequisite (Cilium's