scripts/discover-fortigate: stop hiding SSH errors

First real run returned empty and we had no idea why — the script was
silently swallowing stderr via `2>/dev/null`. Remove the suppression
and try both `execute dhcp lease-list all` and the no-arg form, keeping
whichever returns non-error output.

Also emit a clearer diagnostic when both fail, pointing the user at
an interactive SSH to poke at command syntax.

scripts/discover-fortigate.sh

@@ -35,14 +35,22 @@ USER="${FORTIGATE_SSH_USER:-admin}"
 
 # FortiGate CLI command. `execute dhcp lease-list all` dumps every vdom.
 # If the device is single-vdom, `execute dhcp lease-list` (no arg) also works.
-# Send via stdin so we don't rely on interactive shell handling.
-raw=$(ssh -o BatchMode=no -o StrictHostKeyChecking=accept-new \
-        "${USER}@${HOST}" 'execute dhcp lease-list all' 2>/dev/null \
-      || ssh -o BatchMode=no -o StrictHostKeyChecking=accept-new \
-           "${USER}@${HOST}" 'execute dhcp lease-list' 2>/dev/null)
+#
+# Do NOT suppress stderr — FortiGate's error messages are the main debugging
+# signal when the command returns empty. Let them flow to the caller.
+
+raw=""
+for cmd in 'execute dhcp lease-list all' 'execute dhcp lease-list'; do
+  raw=$(ssh -o StrictHostKeyChecking=accept-new "${USER}@${HOST}" "$cmd" || true)
+  if [ -n "$raw" ] && ! grep -qiE 'unknown action|parse error|command fail' <<<"$raw"; then
+    break
+  fi
+done
 
 if [ -z "$raw" ]; then
-  echo "error: no lease data from $HOST (check SSH access / admin creds)" >&2
+  echo "error: no lease data from $HOST" >&2
+  echo "       — try running 'ssh ${USER}@${HOST}' interactively and running" >&2
+  echo "         'execute dhcp lease-list ?' to discover the right subcommand shape" >&2
   exit 1
 fi