Hardening suggestion: answer hsmd requests that the signer rejects every time #752

Follow-up to #739 / #740 (by @ScuttoZ). Thanks for the signmessage guard. It already handles the case we hit.

While integrating Greenlight with Alby Hub (https://github.com/proxy/gist.github.com/welliv/cf1f9b22a3b9047e5a31f6dc4cc2de24) we read the signer path at main @ 15b22cf. This is a small, non-urgent suggestion.

Observation

• gl-plugin/src/node/mod.rs respond_hsm_request (~L606-655) returns without stage.respond() in three cases: a signer error, a state-merge error, or a state-store write error.
• gl-plugin/src/hsm.rs:96 (chan.recv().await) waits with no timeout, and lightningd's hsmd client is serial.
• Your design already limits the impact. Unanswered requests are replayed to every new signer connection (stager.rs), so transient failures recover.
• Only a request the signer rejects every time can block that hsmd client until the node restarts. node/wrapper.rs:550-556 describes the same mechanism for signmessage.

Suggestion

• For a deterministic signer rejection, answer the waiting request with an hsmd error (or fail the originating RPC) instead of leaving it queued.
• Or add a bounded wait in hsm.rs. stuck_request_types() could drive an alert.

Small extras (happy to split out)

• glcli prints new mnemonics to stdout (gl-cli/src/node.rs:276, scheduler.rs:100).
• glcli writes the seed, credentials and convert-backup output with File::create (0644 under a typical umask). Suggest 0600.
• glcli exits 0 on RPC failures, so wrappers have to parse the output.

Happy to send a PR for any of these if you'd like one.