send-message --wait 5s can block for 30-60s on a dead peer; unknown flags are silently accepted

[artemiia]

send-message --wait 5s can hang for 30 to 60 seconds when the peer is down, and unknown flags are silently ignored.

Environment: macOS 15 (Darwin 24.5, arm64), node upgraded from a March v1.2.x build to v1.13.10 via curl -fsSL https://pilotprotocol.network/install.sh | sh on 2026-09-24. Daemon managed by launchd.

What happened
Against an unreachable directory agent:

time pilotctl send-message frankfurter-latest --data "/data {}" --wait 5s
error: cannot connect to 0:0000.0000.4370 (data exchange port 1001)
30.13s total

A second run of the same command ran for a full 60 s until an external timeout killed it. --wait only bounds the reply phase; the handshake and connect phases have their own fixed 5 s + ~25 s (sometimes longer) budgets that the caller cannot shorten. An agent that asks for a 5 s wait can stall for a minute.

Also:

pilotctl send-message catfact-ninja --data "/data {}" --wait 5s --timeout 5s   # accepted, ignored
pilotctl send-message catfact-ninja --data "/data {}" --wait 5s --bogusflag    # accepted, ignored

No error for flags the command does not have, which hides typos and makes --timeout look like it works.

Expected
--wait (or a separate --timeout) should cap total wall time including connect; unknown flags should be rejected.