feat(pairing-cli): source --nsec - reads the key from stdin, never argv

[lodar]

buzz-pair source transfers a real secret key. Today its only form is --nsec <bech32> — an
argv element, and argv is world-readable in /proc/<pid>/cmdline for the entire life of the
process. For a source session that is up to the 120s it spends waiting for the target to show
up. Any local user, and anything that snapshots the process table, gets the key.

The change

--nsec - takes the key from the first line of stdin instead. It is read before any session
I/O and through the same buffered io::stdin() handle the SAS prompt already uses, a line at a
time — so the interactive y/n answer is simply the next line and the existing flow is unchanged:

{ printf '%s\n' "$nsec"; cat; } | buzz-pair source --nsec - --relay wss://relay.example.com

--nsec <bech32> keeps working exactly as before; this only adds the - form.

The clap help text names both - and the word stdin, so a caller can probe source --help and
refuse to hand a key to a build that does not support it. Help text and behaviour have to move
together, in both directions.

Testing

Graded on the original tree by a 10-arm harness, each arm a measurement rather than an assertion.
The two non-vacuity guards are (a) a released binary without the change failing the help probe,
and (b) a positive leak control that passes the key literally and does find it in
/proc/<pid>/cmdline — without that arm, "no key in argv" would prove only that the probe is blind.

resolve_payload reads real stdin, so the - path is not reachable from a unit test without
refactoring the read behind a trait; the harness covers it as a subprocess instead. Happy to add
that refactor if you'd prefer the coverage in-tree.