Relay authentication challenges can exhaust memory

The SDK forwarded every NIP-42 `AUTH` challenge received from a relay through an
unbounded command queue. Challenge handling can wait for an asynchronous signer or
user interaction, so receiving challenges was substantially faster than completing
the corresponding authentication work.

A malicious relay could continuously send new challenges without authenticating or
delivering valid events. Every value remained queued, causing memory use and pending
signer operations to grow without a fixed limit until the client became unavailable.
The issue does not allow the relay to forge a signature or learn the client's private
key.

The SDK now coalesces pending challenges through a latest-value channel. NIP-42 makes
an earlier challenge invalid when the relay sends a new one, so replacing pending
work preserves the only challenge that can still be answered while keeping memory
use bounded.