Defer busy Companion TX-power updates without interrupting RX

A settings save could reach the power setter while RX, TX, duty cycling or a
profile transition owned the radio, returning BAD_STATE after earlier settings
had already saved. Distinguish busy admission from a hardware rejection and
reuse the existing command route, storage and three-second deadline for power.
Acknowledge only after hardware acceptance and a successful preference save.

Skip hardware work for verified unchanged power. Invalidate that verification
after failed writes or radio initialization, retaining rollback and exclusive
beacon/Morse ownership. Keep the existing firmware memory limits and features.

Cover retries, captured routes, timeout/rollover, disconnect, partial writes,
failed saves and recovery. Keep ESP-NOW/simulation adapters compatible and add
ESP-NOW Companion compilation to the existing sequential smoke job.

docs/companion_protocol.md

@@ -246,6 +246,12 @@ catalog; bytes `0x2C`-`0x31` are parked and `0x35` is unused.
 The sections below detail the most common frames. Refer to the source named
 above for command bodies that are not expanded here.
 
+Radio changes (`0x0B`, `0x0C`) can wait briefly for a safe radio window before
+replying. TX power waits up to three seconds when reception or transmission is
+busy. Its OK response confirms both hardware acceptance and a saved setting;
+timeout or disconnect discards a waiting power change. Successful settings
+commands are saved independently, so an error does not undo earlier commands.
+
 ### Private text when only the sender knows the recipient
 
 Clients continue to send an ordinary `CMD_SEND_TXT_MSG` (`0x02`) with