fix(#529): correct the rationale comment, the tail is scheduling not execution

The comment justified not modelling command execution time by claiming
`wifi on 30` does real work bringing up an interface. It does not. The
firmware handler sets a persistence deadline and sprintf's its reply
immediately (CommonCLI.cpp, "wifi on"), so execution is near-instant.

The owner caught it: he recalled reissuing the command several times
against on-screen errors, not one command taking 20 seconds.

The measurement supports him. On the 20.33 s case the reply carried
claimed=01:56:32 against a command sent at 01:56:26.938, and the RF frame
did not reach our radio until 01:56:47.271979. So roughly 5 s to reach the
repeater and be answered, then roughly 15 s in its transmit queue. The
tail is scheduling on both radios.

No behaviour change. The budget is unchanged and still has to tolerate a
20.33 s round trip; only the stated reason was wrong, and a wrong reason
in a load-bearing comment re-causes the bug later.

lib/connector/meshcore_connector.dart

@@ -5788,11 +5788,15 @@ class MeshCoreConnector extends ChangeNotifier {
   /// 4. [messageRetrievalBudgetMs], because the reply is not pushed to us. The
   ///    radio raises `MSG_WAITING` and we must ask for it.
   ///
-  /// Command execution time is deliberately not modelled. Measured round trips
-  /// to a single repeater ranged from 1.65 s to 20.33 s, and the *same* verb
-  /// (`wifi on 30`) returned in both 2.31 s and 20.33 s, so execution cost is
-  /// not a per-verb constant that could be tabulated. The retrieval term is
-  /// what carries that tail.
+  /// The tail is transmit scheduling, not command execution, and neither end
+  /// exposes it. Measured round trips to one repeater ranged from 1.65 s to
+  /// 20.33 s, and the *same* verb returned in both 2.31 s and 20.33 s. On the
+  /// 20.33 s case the repeater stamped its reply about 5 s in and the packet
+  /// did not reach us for another ~15 s, so the time went into queueing on
+  /// both radios, not into running the command: `wifi on N` only sets a
+  /// deadline and returns immediately (firmware `CommonCLI.cpp` "wifi on").
+  /// Nothing here is a per-verb constant that could be tabulated, so the
+  /// retrieval term is what absorbs it.
   ///
   /// The reply leg uses physics only. The predictor is trained on direct-message
   /// ACK latency, not on command round trips, so asking it about a reply leg

test/connector/cli_timeout_test.dart

@@ -4,8 +4,11 @@
 //
 // Measured against rpt-01: 27 commands, 12 replies, and 4 of those 12 arrived
 // after the 4074 ms window had expired (6.17 s, 8.28 s, 15.52 s, 20.33 s;
-// median 2.75 s). The same verb `wifi on 30` returned in both 2.31 s and
-// 20.33 s, so the tail is not a per-command constant that could be tabulated.
+// median 2.75 s). The same verb returned in both 2.31 s and 20.33 s. The tail
+// is transmit scheduling on both radios, not command execution: on the 20.33 s
+// case the repeater stamped its reply ~5 s in and the packet took another ~15 s
+// to arrive, and `wifi on N` only sets a deadline before replying. So it is not
+// a per-command constant that could be tabulated.
 //
 // These tests pin the budget's construction and, just as importantly, pin that
 // the direct-message ACK path was NOT changed.