Fix framed keepalive ping handling

[iteemoo6]

Summary

• consume OpenVPN data-channel keepalive pings after compression or fragment framing is decoded
• cover both byte-slice and buffer receive paths
• add a regression test for LZO-framed keepalive pings

Root cause

The peer session checks for openVPNDataChannelPingPayload before client data framing is decoded. When LZO framing wraps a keepalive, the peer-level check sees the marker plus the ping and does not recognize it. dataChannelFraming.Decode later removes the marker, but the restored 16-byte keepalive is then queued as tunnel data and reaches the sing-box IP stack as a non-IP packet.

The rejected payload was:

2a187bf3641eb4cb07ed2d0a981fc748

This change repeats the keepalive check immediately after framing decode, before packets enter the client data queue.

Related to SagerNet/sing-box#4344.

Validation

• go vet ./...
• go test ./...
• go -C test test ./...
• the new regression test fails on 64b754d1c277 in both receive paths and passes with this change
• a local OpenVPN 2.7.5 server using LZO framing and a 2-second ping interval remained connected with a sing-box build using this branch; the stock dependency reproduced invalid IP packet on the first ping