v0.3.4 — wss:// delivery stall fix (works on damus)

Fixed

A running signer connected and subscribed to a public wss:// relay but requests published by a client arrived late or never, so the client hung. This was not NIP-42 AUTH (damus delivers kind:24133 unauthenticated) — it was a receive-path stall.

The std TLS reader decrypts one record at a time into its own buffer. IoStream.read returned bytes via the generic readVec into the full 4 KiB receive buffer, which greedily keeps reading until that buffer fills — so a relay message that had already arrived was drained into the buffer and then the read blocked on the next TLS record to fill the rest, withholding the message until unrelated later traffic (a client retry, a relay ping) happened to arrive. Every NIP-46 request stalled behind the following record.

read now serves already-buffered bytes and otherwise does exactly one underlying read (fillMore), so each message surfaces the moment its record lands — on both ws:// and wss://. Supersedes the #44 / #46 read iterations, which fixed the handshake but left this stall. Adds regression tests modeling the real fill-your-own-buffer reader contract.

Verified live against relay.damus.io: a full NIP-46 round-trip (client connect → signer ACK → sign_event → signed reply) completes in ~3 s at sub-second per-request latency, returning a valid signed event. (#48, #49)

Full changelog: https://github.com/zig-nostr/nostr/blob/main/CHANGELOG.md