Fix potential exit node crash and unbounded LZ4 decompression

[RinZ27]

While testing the tunnel stability under heavy load, I noticed a scenario where the exit node process crashed unexpectedly due to a slice bounds panic in the raw socket readLoop. The code was calculating ipHeaderLen from the first byte of the IP packet, but if a truncated or malformed packet arrives where this length exceeds the actual bytes received, slicing pktCopy[ipHeaderLen:] panics instantly. Because this loop isn't wrapped in SafeGo, the panic takes down the entire tunnel.

Added a quick bounds check before the slice operation in both Linux and Darwin raw socket endpoints to fix that. If ipHeaderLen + 20 is larger than the packet size, the code just skips it now.

Another issue caught my attention in compressor.go regarding how LZ4 decompression is handled. The current implementation uses an unbounded io.ReadAll on the LZ4 reader, which means a tiny crafted compressed payload could decompress into gigabytes of zeros. That would easily cause an OOM crash on either the client or the exit node, so capping it with io.LimitReader limits the output to a safe 10MB to prevent any decompression bomb issues.

[damnurmum]

Can confirm both issues are real - checked against our fork (damnurmum/OpenFlux-Android), which carries compressor.go and the raw-socket endpoints byte-identical to main.

The unbounded LZ4 io.ReadAll in particular is a genuine decompression-bomb vector on both sides of the tunnel (client and exit node both run untrusted-input decompression on whatever the transport hands them), not just an exit-node concern, so the io.LimitReader fix is worth having regardless of the raw-socket panic fix. We'll be applying the same bound on our end either way - happy to see this land here too so it doesn't have to live as an undocumented fork-only patch.

[RinZ27]

The Darwin raw socket code got removed upstream anyway, so the fix there is no longer needed. @damnurmum glad to hear the LZ4 limit is useful for your fork as well