Remove CXPLAT_FRE_ASSERT around QuicCryptoFrameEncode (#6102)

## Description

`QuicCryptoFrameEncode` legitimately returns `FALSE` when the CRYPTO
frame would not fit in the remaining QUIC INITIAL packet payload. On
`release/2.5`, `recvfuzz`'s `WriteCryptoFrame` wraps this call in
`CXPLAT_FRE_ASSERT`, which crashes the process with
`STATUS_ASSERTION_FAILURE` (0xC0000420) before any actual fuzzing
happens.

This is currently firing deterministically on the `recvfuzz (Debug,
windows, WinServerPrerelease, x64, schannel, -Test)` stress job: the
schannel ClientHello on the WinServerPrerelease image is ~1521 bytes
(offers ML-KEM keyshares), which does not fit in the ~1170-byte INITIAL
payload `recvfuzz` budgets for it.

A fuzzer should not assert on the return value of an encode helper
anyway. This change just drops the `CXPLAT_FRE_ASSERT` wrapper, matching
the behavior already present on `main` (commit `cc81b151b`, PR #5727).
The TODO on `main` about properly fragmenting CRYPTO frames across
multiple INITIAL packets still applies and is tracked separately.

Root-cause analysis was done from a process dump captured via diagnostic
PR #6101 (now closed).

## Testing

Existing CI matrix (Stress workflow recvfuzz job) is the test: it
crashes deterministically on `release/2.5` today and should stop
crashing with this change. Verified locally that the Debug x64 schannel
build succeeds.

## Documentation

No documentation impact.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Author: guhetier

src/tools/recvfuzz/recvfuzz.cpp

@@ -541,12 +541,11 @@ void WriteCryptoFrame(
         0, ClientContext->State.BufferLength, ClientContext->State.Buffer
     };
 
-    CXPLAT_FRE_ASSERT(
-        QuicCryptoFrameEncode(
-            &Frame,
-            Offset,
-            BufferLength,
-            Buffer));
+    QuicCryptoFrameEncode(
+        &Frame,
+        Offset,
+        BufferLength,
+        Buffer);
 }
 
 //