v0.12.0: Response-scoped notification barrier

A focused bug-fix release that hardens Connection's notification synchronization. No schema changes, no generated API changes, no migration required.

Fixed

• WaitGroup reuse panic under concurrent requests (#30 by @ThomasK33). SendRequest[T] / SendRequestNoResult previously called Wait() on a shared sync.WaitGroup after every response. With overlapping requests — most reproducibly ClientSideConnection.LoadSession replaying session/update notifications on a resumed session — two waiters could race the counter's reuse and trigger sync: WaitGroup is reused before previous Wait has returned.

  The shared barrier has been replaced with a response-scoped, monotonic notification-sequence barrier:

  • Each accepted notification is assigned a sequence number when it is queued.
  • When a response is observed, the receive goroutine snapshots the current notification watermark and attaches it to the response envelope.
  • The waiting request blocks (via sync.Cond) only until completed notifications reach that snapshotted watermark — so it waits for notifications that arrived before the response, but not for any that arrived after.

  Notification ordering is still preserved by the single-consumer processNotifications goroutine, and shutdown still drains through the final queued notification with the existing 5s timeout. The public API is unchanged.

Changed

• Cancellation while waiting for pre-response notifications no longer deadlocks. If the connection context is canceled while a request is blocked on its notification barrier, the call now returns a connection error promptly. Previously the shared WaitGroup could keep the caller blocked indefinitely in this case.

Full Changelog: v0.11.7...v0.12.0