fix(k1): admit live rerun only after real data

docs/runbooks/K1_OPERATOR_FLOW_INCREMENTAL_ACCEPTANCE.md

@@ -1,6 +1,6 @@
 # K1 operator flow: incremental acceptance
 
-Status: working acceptance ledger, 2026-08-14.
+Status: working acceptance ledger, updated 2026-08-20.
 
 This is the short regression anchor for changes to the existing K1 operator
 flow. The authoritative connection and safety model remains
@@ -71,7 +71,19 @@ Current violations observed on 2026-08-14:
   policy again admits Scan plus read-only configured-device observation.
 - `K1-P0-RERUN-ADMISSION`: backend decoded and published PCL, but the browser
   never admitted the active Rerun store; camera/counters were visible over an
-  empty point scene. Not fixed in the checkpoint increment.
+  empty point scene. Offline fix and reducer are green: store discovery is only
+  a candidate, presentation requires a usable range plus a backend-published
+  frame, and recovery-authority churn no longer remounts the same receiver.
+  Production raw replay of `20260814T145329Z_viewer_live` rendered the real
+  point scene with `Визуализатор готов` and `Повтор записи`. One live K1
+  READY → START → point cloud/camera → STOP acceptance remains required; the
+  2026-08-20 attempt was blocked before discovery by the unceased checkpoint
+  described below.
+- `K1-P0-RESET-CHECKPOINT`: an explicit local scenario reset resolved a
+  zero-dispatch START as `not-dispatched`, but left its exact recovery
+  checkpoint revision 17 in `prepared`. No device/network command was sent;
+  the stale checkpoint blocks the next START and requires a local atomic
+  settlement fix before live acceptance continues.
 - `K1-P1-STOP-STABILITY`: STOP authority visibly oscillated before the operator
   clicked. Not fixed in the checkpoint increment.
 - `K1-P1-PENDING-FEEDBACK`: reconnect/search/select/provision transitions replace