feat(STATE-WP-0064): start parallel week with source-tagged sweep runners

Tag consistency_sweep_remote_all progress events by source, route the local
timer through the API, add a parallel-week comparison script, and document
the 2026-06-21 to 2026-06-28 observation window for T03.

docs/consistency-sweep-runbook.md

@@ -65,7 +65,7 @@ Expected definition:
 - trigger: `*/15 * * * *`
 - timezone: `UTC`
 - misfire policy: `skip`
-- enabled: `false` until manual canary passes, then `true` after cutover
+- enabled: `true` during parallel week (T03); local timer retired after T04
 
 ## Progress Event Check
 
@@ -113,6 +113,27 @@ Before enabling the cluster schedule:
 3. Verify the progress event and ActivityRun context snapshot.
 4. Confirm idempotence when the local timer also fires (lock skip is OK).
 
+## Parallel week observability (T03)
+
+Both runners call the same API and tag progress events with `detail.source`:
+
+| Source | Runner |
+|--------|--------|
+| `local-timer` | `custodian-sync.timer` on the workstation |
+| `activity-core` | Railiance01 Temporal schedule |
+
+Summarise evidence:
+
+```bash
+cd ~/state-hub
+uv run python scripts/compare_consistency_sweep_parallel.py --since-hours 24
+```
+
+Expect some `lock_skipped: true` events when both schedules overlap — that is
+healthy idempotence, not duplicate work.
+
+Parallel window: **2026-06-21 → 2026-06-28** (review before T04 cutover).
+
 ## Cutover
 
 After one parallel week (`STATE-WP-0064-T03`):
@@ -121,5 +142,4 @@ After one parallel week (`STATE-WP-0064-T03`):
 systemctl --user disable --now custodian-sync.timer
 ```
 
-Then enable the activity-core definition and treat the cluster schedule
-as the sole primary runner.
+The cluster definition stays enabled; disable only the local timer.