fix(k1): gate control dialogue on live state

docs/adr/0012-device-bound-k1-command-authority.md

@@ -37,10 +37,14 @@ K1 application control is exact-profile, live-bound and fail-closed.
 3. The BLE-selected transport is followed by an unbound DeviceInfo exchange.
    Its live vendor ID, serial, activation and FW 3.0.2 facts form the transient
    device binding; a saved profile is optional metadata, not protocol authority.
-4. The ten retained pre-START requests keep their exact order and response
-   boundaries. The only mutation is the observed time/timezone sync; the other
-   nine requests are reads. No request is batched, skipped or automatically
-   retried.
+4. The complete retained START lifecycle keeps its 14-operation order, stage
+   boundaries and one continuous control MQTT session. The first ten operations
+   are pre-START; operation 11 is START; operation 12 is a bound ModelingStatus
+   read; operations 13–14 are the post-initialization DeviceInfo/ModelingStatus
+   refresh. The only preparatory mutation is time/timezone sync. No stage is
+   collapsed, skipped or automatically retried. Captured wall-clock gaps are
+   operator/UI timing, not protocol delays. Stage progression uses explicit UI
+   actions and live K1 state reports.
 5. Live DeviceInfo binding must agree with the live DeviceStatus stream before
    START/STOP planning. Identity drift, malformed data, inactive equipment,
    profile mismatch or an unexpected lifecycle state fails closed.
@@ -55,7 +59,7 @@ K1 application control is exact-profile, live-bound and fail-closed.
    quiescence/evidence sealing, READY plus steady green, then independent native
    project verification.
 
-## Recovered pre-START sequence
+## Recovered START sequence
 
 The clean cycle contains:
 
@@ -70,6 +74,9 @@ The clean cycle contains:
 9. bound `GetRtkAdvanceRequest`;
 10. bound `DeviceInfoRequest`;
 11. bound `ModelingRequest` START.
+12. bound `ModelingStatusRequest`;
+13. bound `DeviceInfoRequest` after static initialization;
+14. bound `ModelingStatusRequest` after static initialization.
 
 Normal sessions are `${device_id_or_empty}:${MessageType}`. Time sync uses the
 captured special relation
@@ -115,9 +122,20 @@ An unknown post-publish outcome can only be reconciled physically/status-wise;
 the same operation key can never be attempted again by that transport.
 
 The acceptance executor requires a 15–120 second single-action permit backed by
-five explicit operator confirmations. START cannot skip the five recovered
-bootstrap batches; STOP uses a separate permit. These types are not imported by
-the facade, declared as plugin actions or represented by UI controls.
+five explicit operator confirmations. After the failed 2026-07-18 physical
+attempt proved that five response batches alone are insufficient, the collapsed
+bootstrap entry point and standalone START/STOP were disabled. The uninstalled
+replacement binds requests 1–6 to connection, request 7 to scan-workspace entry,
+requests 8–10 to project-prompt entry and START to a separate operator permit.
+There is no separate project-name mutation; the validated name is carried by
+START. Operations 13–14 are gated by bound `SCANNING`, project presence and
+`init_ready`, not by the observed 24–25-second duration. The same owner services
+MQTT through explicit STOP and waits for live READY plus operator-confirmed
+standby. Fault/status observations are redacted and any fault forbids automatic
+continuation. The socket remains serviced during operator/UI waits, and each
+short action permit is created at its button confirmation rather than at
+connection time. These types are synthetic-test-only, not imported by the facade,
+declared as plugin actions or represented by UI controls.
 
 `MacOSKeychainApplicationAuthorityProvisioner` invokes Apple's interactive
 `security add-generic-password ... -w` prompt with `-w` last. The private value
@@ -133,10 +151,11 @@ transport:
 
 1. provision the reviewed private authority into the fixed local Keychain item;
 2. confirm battery/storage and select one K1 over BLE;
-3. run the exact response-gated bootstrap and attest activated FW 3.0.2;
+3. run the exact staged response-gated preparation and attest activated FW 3.0.2;
 4. confirm READY identity against DeviceInfo and review shadow metadata;
 5. send one START without retry and correlate its response;
-6. observe calibration and first point/pose/camera data;
+6. preserve the same control MQTT connection, issue the retained post-START
+   reads and observe calibration plus first point/pose/camera data;
 7. send one STOP without retry and correlate its response;
 8. seal local evidence while accepting the bounded stream tail;
 9. wait for READY and steady green;