Fix #1725: a control request its caller timed out on is withdrawn, not run later

The worker answered "timeout" after 60 s and left the request on the queue, so
the app ran it whenever it next drained the queue: an edit nobody was waiting
for, and a second one if the caller had retried. A request now leaves the
queue once: taken by the app, or given up by its caller, whichever comes
first. The timeout reply says which ("will not run" / "still running").

docs/control-protocol.md

@@ -43,6 +43,12 @@ and does not append a partial gesture. Clients can retry once earlier input has
 scheduled. These limits cover synthetic input admission, separately from socket transport and
 command-processing timeouts.
 
+A request the app hasn't answered after **60 s** gets `{"ok": false, "error": "timeout: …"}`. If the
+app had not started it (it was busy, or its window wasn't being drawn), the request is withdrawn
+and never runs, and the error says "will not run": retrying is safe. If the app was already
+running it, the error says "still running": it may yet complete, so check the document before
+retrying.
+
 ## Confining file access
 
 ```sh