fix: use ws library for Bun runtime in getGlobalWebSocket

[rogerpadilla]

Summary

Fixes #466

Bun's native WebSocket constructor ignores the 3rd options argument (including headers), which silently drops the Authorization header when connecting to Deepgram's WebSocket API. This causes the connection to fail with readyState: 3 (CLOSED) immediately.

Changes

src/core/websocket/ws.ts

• Modified getGlobalWebSocket() to skip Bun's native WebSocket and fall back to NodeWebSocket (ws library) when RUNTIME.type === "bun"
• The ws library correctly supports custom headers in its constructor

tests/unit/websocket-bun-runtime.test.ts

• Added unit tests verifying the runtime selection logic for Bun, Node, browser, and unknown environments

Root Cause

// Before: Bun hits the first condition because it has a native WebSocket global
if (typeof WebSocket !== "undefined") {
    return WebSocket; // Bun's native - ignores headers
} else if (RUNTIME.type === "node") {
    return NodeWebSocket; // Never reached for Bun
}

// After: Bun is excluded from native and included in NodeWebSocket fallback
if (RUNTIME.type !== "bun" && typeof WebSocket !== "undefined") {
    return WebSocket;
} else if (RUNTIME.type === "node" || RUNTIME.type === "bun") {
    return NodeWebSocket; // ws library - supports headers
}

Testing

• Unit tests added for runtime selection logic
• Manually verified with Bun v1.3.10 that ws library establishes successful WebSocket connections with Deepgram