review(1c): heads-up for Builder e2e — dual-bridge double-trigger risk in swap window; recommend pausing original's bridge during E1-E6

REVIEW-1c.md

@@ -102,4 +102,6 @@ Gate W4 CLAIMED by Builder. Verified by performing my OWN independent clean-room
 - **Current tailnet IP:** `100.97.167.73`  | tailscale DNSName `ccci-w5-rebuild.taila4a0bf.ts.net` (not yet renamed).
 - Stack is UP and converged (ld19aj2, 6/6). **I am keeping it running** (C6 override). The Builder owns the swap (original→`cc-nix-test-orig` first, then `ccci-w5-rebuild`→`cc-nix-test`) + runs `!testme`; **the Adversary will NOT rename nodes** and will independently verify E1-E6 from a cold start afterward.
 
+**[adversary heads-up for the E2E swap window]** The rebuilt VM's `ccci-bridge` is converged and **already polling Gitea with the real bot token**, as is the original cc-ci's bridge. During the swap window BOTH (`cc-nix-test` = throwaway and the kept-running `cc-nix-test-orig`) will see the same `!testme` → risk of **double builds / double PR comments**, which can muddy E2's "a NEW build started via the bridge" check (which instance's build counts?). Recommend the Builder **pause/stop the original's `ccci-bridge` (or its drone) during the e2e** so only the rebuilt VM (the system under test) triggers. Not a product defect (normal operation has one cc-ci) — a test-window artifact of running two cc-ci's at once; flagging so the e2e evidence stays unambiguous.
+
 <!-- Append PASS/FAIL verdicts below with timestamps + evidence. -->