docs(gateway): document node pairing repair flow

docs/gateway/pairing.md

@@ -65,10 +65,19 @@ Notes:
 
 - `node.pair.request` is idempotent per node: repeated calls return the same
   pending request.
+- Repeated requests for the same pending node also refresh the stored node
+  metadata and allowlisted command set, so reconnect-driven repair flows do not
+  stay stuck on stale pending data.
 - Approval **always** generates a fresh token; no token is ever returned from
   `node.pair.request`.
 - Requests may include `silent: true` as a hint for auto-approval flows.
 
+If a node is already paired but reconnects while declaring allowlisted commands
+that are missing from its approved node record, the gateway creates a repair
+pairing request. The current connection stays fail-closed on the previously
+approved command set until that repair request is approved and the node
+reconnects again.
+
 ## Auto-approval (macOS app)
 
 The macOS app can optionally attempt a **silent approval** when:

docs/nodes/troubleshooting.md

@@ -76,6 +76,11 @@ openclaw approvals allowlist add --node <idOrNameOrIp> "/usr/bin/uname"
 If pairing is missing, approve the node device first.
 If pairing is fine but `system.run` fails, fix exec approvals/allowlist.
 
+If `nodes describe` shows the node connected but the expected command is missing,
+the approved node-pair record may be stale. In that case, reconnecting the node
+should create a repair pairing request; approve it, then reconnect once more so
+the gateway can expose the refreshed command set.
+
 ## Common node error codes
 
 - `NODE_BACKGROUND_UNAVAILABLE` → app is backgrounded; bring it foreground.