fix(pairing-cli): send the JSON envelope the apps decode, and stop panicking on wss://

[lodar]

Two defects that together make it impossible to pair a handset with the Buzz mobile app against an
HTTPS relay. Both measured against a live relay, not by inspection.

1. The payload shape the apps cannot decode

resolve_payload returned a bare bech32 nsec as PayloadType::Nsec in both arms. Mobile
_processPayload begins with jsonDecode(payload) as Map<String, dynamic>, and nothing in
mobile/lib branches on payload_type, so a bare nsec dies on the leading n with:

FormatException: Unexpected character (at character 1)

That is verbatim what a real store build produced on a real handset.

--envelope-relay <https url> now emits the same shape the desktop client already sends
(desktop/src-tauri/src/commands/pairing.rs:145-148, PayloadType::Custom at :215):
{"relayUrl","pubkey","nsec"}. pubkey is derived from the transferred nsec, so the two cannot
drift.

Without the flag the payload is unchanged, so existing CLI-to-CLI interop testing keeps working
exactly as before.

2. wss:// panicked before any pairing could start

thread 'main' panicked at rustls-0.23.42/src/crypto/mod.rs:249:14
Could not automatically determine the process-level CryptoProvider

Both ring and aws-lc-rs are reachable in the workspace, so rustls refuses to choose. Plain
ws:// never reaches that code path — which is why interop testing done entirely against a
plaintext relay was structurally blind to it: the defect exists only past the TLS an HTTPS
deployment adds. The fix pins the ring provider and installs it at the top of main().

Cargo.lock records the new direct rustls dependency; without that hunk the tree does not build
under --locked.

Testing

Verified end to end against a live HTTPS relay: wss:// connects instead of panicking, and a real
mobile build decodes the envelope and completes pairing. --envelope-relay-less runs are
byte-identical to before.