Control: requests are answered at full speed while the window is hidden on macOS

Within about a minute of its window no longer being visible, macOS App
Nap lowers the app's threads to the lowest priority and coalesces its
timers. On a loaded machine, control requests then took seconds to
answer, and the 60 s timeout reply arrived up to 26 s late.

When the control channel is on (--control or VECTORCRAFT_CONTROL_PORT),
the app now holds an NSProcessInfo activity (user initiated, allowing
idle system sleep, latency critical) for as long as it runs, so App Nap
does not apply. The activity does not keep the Mac awake.
docs/control-protocol.md states this in the paragraph on the 60 s
timeout.

docs/control-protocol.md

@@ -51,7 +51,8 @@ A request the app hasn't answered after **60 s** gets `{"ok": false, "error": "t
 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.
+retrying. On macOS the app keeps itself out of App Nap while the control channel is on, so it keeps
+answering with its window hidden, minimized or covered, or with the screen locked.
 
 ## Confining file access