1c: record Drone-token clean-room finding+fix in journal

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

JOURNAL-1c.md

@@ -353,3 +353,19 @@ its W5 VM up, **records the VM identity (Incus instance + current tailscale IP)
 and independently VERIFIES E1-E6 cold (critic role). So I **WAIT for (i) Adversary W5 PASS + (ii) the
 recorded VM IP** before swapping (original→cc-nix-test-orig, then ccci-w5-rebuild→cc-nix-test). Updated
 STATUS-1c pending-e2e accordingly. Still gated on W5 — not started.
+
+## 2026-05-27 — E2E-TESTME clean-room finding: Drone bot token not reproducible (FIXED in git)
+
+Doing the e2e setup on the swapped-in rebuilt VM, found the sops `bridge_drone_token` gets **401
+Unauthorized** from the rebuilt VM's Drone. Root cause: `modules/drone.nix` set
+`DRONE_USER_CREATE=username:autonomic-bot,admin:true` with **no `token:`** → Drone auto-generates a
+RANDOM bot machine token in its fresh DB, which can't equal the committed sops token (the original
+cc-ci only matched because its token was captured FROM the running Drone out-of-band). So on a genuine
+clean-room rebuild the bridge can't authenticate to Drone → can't trigger builds. This is precisely the
+out-of-band gap the E2E-TESTME is designed to catch (spec §4). **Fix (git source):**
+`DRONE_USER_CREATE=...,token:$(cat /run/secrets/bridge_drone_token)` so the bot's machine token is the
+deterministic sops token on every rebuild. Confirmed via: rebuilt Drone container env had no token;
+`GET /api/repos/.../builds` with sops token → `{"message":"Unauthorized"}`.
+Evolves the toplevel again (ld19aj2 → new); will re-deploy to cc-ci + re-verify byte-identical after
+the e2e, Adversary re-checks C1. Next: apply fix on the rebuilt VM (rebuild → redeploy Drone; wipe
+Drone DB if DRONE_USER_CREATE doesn't update the existing bot), re-run OAuth, then the !testme e2e.