fix: command op replies that said ok when nothing was done

From the review of #100:
- setMyPosition on a moving shade replies busy ("The shade is moving"),
  and setPositions with only a tilt, for a shade without one, replies
  bad request ("The shade has no tilt"). Both said ok before.
- PROTOCOL.md lists where the ops differ from the routes, and how
  sendRemoteCommand is answered.
- The LoopQueue hold comment covers protocol 2 replies and an unpair
  held through a frequency scan.
- One shadeRequestIsForGroup() for the group cases; ProtoOps shares one
  reader for "one or both" fields and one for ids, and the radio
  refused text.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

src/outputs/ProtoSocket.cpp

@@ -170,7 +170,7 @@ static void sendRemoteCommand(AsyncWebSocketClient *client, const proto_message_
   const char *bad = parseRemoteCommandOp(d, frame, repeats);
   if(bad) { replyError(client, req.id, proto_error_t::badRequest, bad); return; }
   if(!somfy.sendFrame(frame, repeats)) {
-    replyError(client, req.id, proto_error_t::radioUnavailable, "The radio didn't take the command");
+    replyError(client, req.id, proto_error_t::radioUnavailable, PROTO_RADIO_REFUSED);
     return;
   }
   replyOk(client, req.id);