SignalR client handshake blocked by WAF due to trailing 0x1E character

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

When using the SignalR client (@microsoft/signalr version 6.0.5), the initial handshake message includes a trailing 0x1E (record separator) character as per the SignalR protocol specification. This causes some Web Application Firewalls (WAFs) to reject the request with a body parse error, such as:
WAF failed to parse the request body: parse error - trailing garbage
This is likely because the WAF attempts to parse the request body as strict JSON, and the 0x1E character is not valid JSON syntax.

### Expected Behavior

The SignalR client should ideally:

Provide a way to configure or suppress the 0x1E delimiter in environments where WAFs are strict.
Or, offer guidance on how to safely bypass WAF inspection for SignalR endpoints.

### Steps To Reproduce

Deploy a SignalR client using JSON protocol over Server-Sent Events or Long Polling.
Place the app behind a WAF (e.g., AWS WAF, Azure WAF, Cloudflare).
Observe the WAF blocking the handshake request due to malformed JSON.

### Exceptions (if any)

_No response_

### .NET Version

microsoft/signalr v6.0.5

### Anything else?

Environment:

SignalR Client: @microsoft/signalr v6.0.5
Server: ASP.NET Core SignalR
Transport: Server-Sent Events / Long Polling
WAF: [e.g., AWS WAF / Azure Front Door / Cloudflare]