WP-0039: record partial cutover; declare the worker map, keep the API image

T02 was done by railiance-platform (CCR-2026-0029/0030). The worker-token
ExternalSecret is live, and the claim-loop token is rotated. The new API image
failed because production is at alembic 0009 and main needs 0010 (WP-0038,
never deployed). It was rolled back within about one minute, and the loop
claims again with HTTP 200. The manifest now declares ACTIVITY_CORE_WORKERS
and keeps the live API image.

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

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 151606@bnt-lap001
Assistant-Session: 3c0a4ad5-bb8b-4bf7-b9f0-fa5f29204e48

k8s/railiance/20-runtime.yaml

@@ -26,6 +26,9 @@ data:
   OPS_RUN_SLA_HOURS: "1"
   # Non-secret identity bound to ACTIVITY_CORE_WORKER_TOKEN at the API boundary.
   ACTIVITY_CORE_WORKER_ID: rein-aharness@railiance01
+  # ACTIVITY-WP-0039: token-to-identity map; each token env is synced from its
+  # own OpenBao path by 15-externalsecret-worker-tokens.yaml.
+  ACTIVITY_CORE_WORKERS: "rein-aharness@railiance01=ACTIVITY_CORE_WORKER_TOKEN,rein-aharness-metered@railiance01=ACTIVITY_CORE_WORKER_TOKEN_METERED"
   # ACTIVITY_CORE_WORKER_TOKEN lives in actcore-runtime-secret.
   ACTIVITY_DEFINITION_DIRS: /etc/activity-core/external-definitions
   CUSTODIAN_REPO_ROOT: /var/custodian

workplans/ACTIVITY-WP-0039-multi-worker-identity-and-token-custody.md

@@ -81,7 +81,7 @@ fail-closed case, and operator access under broken worker configuration.
 
 ```task
 id: ACTIVITY-WP-0039-T02
-status: wait
+status: done
 priority: high
 state_hub_task_id: "1400bf41-e00a-56cc-9ccf-a1cf023b220a"
 ```
@@ -166,7 +166,7 @@ lands.
 
 ```task
 id: ACTIVITY-WP-0039-T04
-status: wait
+status: progress
 priority: high
 state_hub_task_id: "13e90456-02ff-52e7-9296-1fd80761fab4"
 ```
@@ -196,3 +196,33 @@ The pods read `actcore-runtime-secret` only at start.
    returns HTTP 200.
 
 Report the revision to secrets-engine on threads `914853d9` and `6e694682`.
+
+**Cutover attempt, 2026-09-23 (founder go-ahead, build mode).**
+T02 was done by railiance-platform at 18:06:29Z (CCR-2026-0029/0030, commit
+`fe1665d`).
+
+1. The ExternalSecret `actcore-ops-run-worker-tokens` is applied. Both keys
+   synced at 20:35:35Z, and ESO now owns `ACTIVITY_CORE_WORKER_TOKEN`.
+2. No `ops_run` was claimed. The claim-loop env file was backed up
+   (`claim-loop.env.bak-wp0039-20260923T203559`) and given the new loop
+   token without printing it.
+3. The image `activity-core:wp0039-20260923` (built from `main` at `1a20c85`)
+   was imported. The ConfigMap with `ACTIVITY_CORE_WORKERS` and the API
+   Deployment were applied, and the claim loop was restarted.
+4. **The new API returned HTTP 500** (`column ops_runs.repository_grant does
+   not exist`). Production is at alembic `0009`, and `main` needs `0010` (the
+   WP-0038 columns). The running `fi-publication-20260914` image contains no
+   WP-0038 code, so WP-0038 was never deployed. The API was rolled back to
+   `fi-publication-20260914`, and the loop claimed again with HTTP 200 at
+   20:39:23Z. The outage lasted about 1 minute, and no run was affected.
+
+Live state now: the option-(b) loop token rotation is complete. The old code
+reads the ESO-synced `ACTIVITY_CORE_WORKER_TOKEN`, which is the new value.
+`ACTIVITY_CORE_WORKERS` is in the ConfigMap and is ignored by the old image.
+The metered identity is not live yet.
+
+Remaining: run migration `0010`, which is additive (two nullable columns).
+That also takes WP-0038's close reconciliation live for the first time. Then
+redeploy the API on `wp0039-20260923`, and prove the metered identity and the
+403 cross-identity rejection. Both need the founder's decision because they go
+beyond the worker-identity change.