fix(ws): use uint64 for params.Subscription in incoming notifications

[ozpool]

Closes #286.

Bug

The websocket pubsub response type in rpc/ws/types.go was defined as:

type params struct {
    Result       *stdjson.RawMessage `json:"result"`
    Subscription int                 `json:"subscription"`
}

The validator emits subscription ids as JSON unsigned 64-bit integers. With the field typed as int the decode in decodeResponseFromMessage fails on 32-bit builds for any id above math.MaxInt32, and on 64-bit builds for any id above math.MaxInt64. That is exactly the path users hit in #286: unable to decode client response from SlotSubscribe() (and the same shape for any other ws subscription). The bug was diagnosed in the issue thread by @AliakseiM, who pointed at this exact field.

Fix

Switch Subscription to uint64. The field is not consumed downstream — handleMessage parses the routing key separately via getUint64WithOk — but it has to be present so encoding/json does not error on the inbound notification. uint64 matches what the validator and handleMessage already use everywhere, and lines up with the recent #400 work that hardened request ids against the same JSON-safe-integer footgun.

Tests

TestResponseDecodesLargeSubscriptionID (new) decodes a notification with subscription == math.MaxUint64 to pin the new behavior.

$ go test -count=1 ./rpc/ws/... ./rpc/
ok   github.com/gagliardetto/solana-go/rpc/ws   0.325s
ok   github.com/gagliardetto/solana-go/rpc      0.680s

Diff size

 rpc/ws/types.go      | +9 -2
 rpc/ws/types_test.go | +22

[ozpool]

Hi @sonicfromnewyoke — also ~19 days open with no review. Small ws typing fix — params.Subscription in incoming notifications is parsed as uint64 to match the spec instead of being narrowed. Happy to rebase if needed. Thanks.