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/ProtoOps.h

@@ -27,6 +27,9 @@ const char *parseRemoteCommandOp(JsonObjectConst d, somfy_frame_t &frame, uint8_
 // in any case.  False for a name that isn't a command.
 bool protoCommand(const char *name, somfy_commands &cmd);
 
+// What a reply says when the radio didn't take a command.
+#define PROTO_RADIO_REFUSED "The radio didn't take the command"
+
 // The reply to a shade request that loop() has run: none when it was done.
 proto_error_t protoRequestError(shade_request_result_t result);
 // What that reply says.