Fix: strip RTP padding before DAVE decrypt (RFC 3550 §5.1)

[yury-opolev]

Fixes #3262.

Summary

RTPReadStream.WriteAsync now honors the RTP P (padding) bit per
RFC 3550 §5.1. When the bit is set, the last octet of the packet is
the padding count; those trailing bytes are stripped before the
payload is handed to downstream streams.

Without this fix, any padded packet reaches DaveDecryptStream with
extra bytes appended after the DAVE trailer, and libdave rightly
rejects it — logging Failed to decrypt audio packet for {userId}: DecryptionFailure and silently losing the audio.

Root cause

The count - headerSize slice handed to _next.WriteAsync always
included any trailing padding the sender added. RTP spec:

If the padding bit is set, the packet contains one or more additional
padding octets at the end which are not part of the payload. The last
octet of the padding contains a count of how many padding octets
should be ignored, including itself.

Real Discord clients hit this on a steady background rate (~3%
observed in clean conditions), spiking when silence / DTX boundaries
trigger keepalive / pure-padding packets (saw 50+ such packets in a
single 100 ms burst).

Evidence

Same bot, same private voice channel, same speaker — three back-to-back
30-second runs against the spike diagnostics (extra logging added to
DaveDecryptStream — not in this PR):

Version	Decrypt failures	Attempts	Rate
Stock 3.19.1	63	~1,650	3.8%
+ RFC padding strip	52	~2,710	1.9% (all empty-payload packets)
+ drop empty-payload	0	3,320	0.0%

Byte-level shape of pre-fix failures: variable-looking first four bytes
(ciphertext head) followed by long runs of the same byte at the end
(0E0E…0E, 0D0D…0D, FFFF…FF, 2020…20, 1010…10, C9C9…C9,
5555…55, etc.) — textbook RTP padding. Successes end in the DAVE
trailer 0D FA FA. Confirms the padding hypothesis at the byte level.

Changes

One file, ~25 lines. Self-contained.

Test plan

• Manual: instrumented spike that logs every decrypt result before
  and after the patch. Failure rate went from 3.8% → 0.0% over
  ~3300 attempts on a single user turn. Transcription quality
  improved correspondingly (more audio reaching the app).
• Build clean on dev branch: dotnet build src/Discord.Net.WebSocket/Discord.Net.WebSocket.csproj -c Release.
• Would appreciate review from maintainers familiar with the DAVE
  pipeline — particularly whether the empty-payload drop is the
  right place for it, or whether it belongs somewhere earlier (e.g.
  in AudioClient before we even reach RTPReadStream).

Scope guardrails

• No API changes.
• No behavior change for packets that don't have the P bit set (the
  vast majority).
• Pure-padding packets that used to produce a spurious log line are
  now dropped silently — an arguable semantic change, but in every
  practical case those packets carry no audio, and the prior behavior
  was noise.