fix(sync): stop prior long-poll on reconnection

[chocycat]

When a client disconnects (browser refresh or network drop) during a sliding sync long-poll, the server continues to hold the connection mutex until the full timeout expires. Any new request from the same client on the same conn_id blocks on acquiring this lock, causing the user to wait for the previous request's timeout before the sync resumes.

This adds a Notify to each connection entry, so when a new request arrives for the same (user, device, conn_id), it notifies the previous handler, which then exits the long-poll loop and releases the mutex. The new request proceeds immediately.

Reproduction

1. Start a sliding sync long-poll with timeout=30000
2. While it's active, make another request with the same conn_id
3. Before the fix: the second request blocks for ~30s
4. After the fix: the second request proceeds immediately

Tested on Tuwunel v1.5.1 with a live server.

[jevolk]

Thank you so much for finding this issue. This is actually a really delicate matter given some of the specific quirks discovered in the SDK and sliding sync. I'm going to need to review this thoroughly.