fix(javascript): flush queued events after WebSocket reconnect

[Dobrunia]

Problem

When the collector WebSocket dropped, the SDK queued outgoing events but only ran sendQueue() after the initial connection in the constructor. After a successful reconnect() (or init() when ws === null), the buffer was never drained, so the first hawk.send() after a disconnect could be lost until a later send.

Solution

• After a successful reconnect(), call sendQueue().
• When ws === null, after await init() call sendQueue().

Tests

• Unit tests for CLOSED → reconnect → queued payload sent.
• Unit test for pagehide → ws === null → send() flushes queue.
• Mock WebSocket must expose numeric CONNECTING / OPEN / CLOSING / CLOSED so switch (readyState) matches real browser behavior.

[Copilot]

Pull request overview

Fixes a JavaScript SDK reliability issue where events queued during a WebSocket disconnect were not being flushed after a successful reconnect (or after re-initializing when ws === null), causing the first send() after connection loss to be delayed/lost until a later send.

Changes:

• Flush eventsQueue after await init() when ws === null in send().
• Flush eventsQueue after a successful reconnect().
• Add regression tests covering CLOSED → reconnect → queued payload sent, and pagehide → ws === null → send() flushes the queue (including a helper to patch WebSocket readyState constants for mocks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
packages/javascript/src/modules/socket.ts	Ensures queued events are drained after reconnect and after re-init from ws === null.
packages/javascript/tests/socket.test.ts	Adds regression tests + improves WebSocket mocking realism by patching static readyState constants.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.