fix(deploy): the ghcr package is private, so declare the pull secret

Same arrangement classic-models already uses: a hand-created ghcr-pull-secret
rather than one committed or held in Vault, since the credential is a GitHub
token that belongs to no estate in particular. Without it the pod would sit in
ImagePullBackOff with no hint as to why.

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

README.md

@@ -155,6 +155,12 @@ the source that serves it exist:
 
 ```
 kubectl apply -f k8s/namespace.yaml
+
+# The ghcr package is private. Copy the pull secret classic-models already has:
+kubectl -n classic-models get secret ghcr-pull-secret -o yaml \
+  | sed 's/namespace: classic-models/namespace: agents/' \
+  | kubectl apply -f -
+
 kubectl apply -f dev/gitrepository.yaml
 kubectl apply -f dev/bootstrap-kustomization.yaml
 ```
@@ -170,6 +176,7 @@ What the deployment assumes:
 | Namespace | `agents` — one for the estate; what isolates an agent is its Keycloak client, not its namespace |
 | Secret | `CATALOGUE_CLIENT_SECRET`, from the same Vault entry the realm import reads, through the `vault-keycloak` store |
 | CA | `k8s/ca-configmap.yaml` holds the lab CA **certificate** — public by construction, checked in so the deployment has no hidden prerequisite. Regenerate it when the CA rotates (expires 2026-11-24) |
+| Image pull | `ghcr-pull-secret` in `agents`, created by hand — the package is private |
 | DNS | every `*.sttlab.local` name resolves in-cluster already; no `hostAliases` needed |
 | Replicas | exactly one. Conversation history lives in the process, so a second replica would route a user's "yes" to a pod that never saw the question |