SIPGO: DoS via unvalidated WebSocket frame length

### Summary The WebSocket transport allocates a buffer from the frame payload length before validating its size, which can lead to an unauthenticated DoS. ### Details `WSConnection.Read` allocates a buffer from the declared WebSocket frame length before reading the payload (https://github.com/emiago/sipgo/blob/v1.4.0/sip/transport_ws.go#L400): ```go data := make([]byte, header.Length) // header.Length is client-controlled, up to 2^63-1 (int64) ``` - `NextFrame()` reads only the frame header and never checks the length: `wsutil.NewReader` is created with no [`MaxFrameSize`](https://pkg.go.dev/github.com/gobwas/ws@v1.3.2/wsutil#Reader.MaxFrameSize) (`0` = unlimited). `ParseMaxMessageLength` applies only downstream, not here. - A value above the max slice size (e.g. `2^63-1`) panics `make`. sipgo does not recover from this panic, so it crashes the whole server process. ### PoC Tested on emiago/sipgo v1.4.0 (latest). After a normal WebSocket handshake, send one masked text frame consisting of the header only (no payload), declaring a huge length. The allocation runs as soon as the header is read. ``` 0x81 FIN + text opcode 0xFF MASK bit + length marker 127 (8-byte length follows) 0x7F FF FF FF FF FF FF FF declared length = 2^63-1 -> make panics (crash) <4-byte masking key> (no payload) ``` This crashes the server process: ``` panic: runtime error: makeslice: len out of range goroutine 23 [running]: github.com/emiago/sipgo/sip.(*WSConnection).Read(...) /path/to/pkg/mod/github.com/