feat(rdpsnd): carry the capture timestamp on waves and surface wave confirms

[Marynych Oleksandr (maryny4)]

MS-RDPEA 2.2.3.10 has the client echo a wave's wTimeStamp back in the Wave Confirm PDU once it consumed, cancelled or dropped that block, which is how a server measures how long the client held the data. The server hardcoded that field to zero for both Wave and Wave2, and the confirm was only logged, never delivered to the handler — so an embedder chasing an audio/video offset has no way to tell "the delay is on my side of the socket" from "the client is buffering".

Waves now carry the low bits of the same capture time the 32-bit dwAudioTimeStamp gets, so both fields describe one instant, and RdpsndServerHandler gains a defaulted wave_confirm(block_no, timestamp) that receives the echo. Existing handlers are unaffected.

This came out of an audio-lag investigation in a downstream server (MuNeNiCK/hypr-rdp#46): on a healthy setup the server side shows nothing — zero stale-wave drops, a send queue of 0 bytes, confirms arriving at ~90/s — but there is no way to quantify the client-side half of the path, because the one field the spec reserves for it is always zero.

Covered by two tests in ironrdp-testsuite-core: a wave carries the low bits of a capture time past the 16-bit range, and a Wave Confirm reaches the handler with its block number and echoed timestamp.