Fix: normalize literal \\r\\n escape sequences in HTTP content from MCP clients

[dhawanmayank]

Problem

MCP clients (e.g. Claude Code) pass \r\n as literal 4-character text escape sequences (\, r, \, n) in JSON tool parameters, rather than actual CR (0x0D) + LF (0x0A) bytes.

The existing line-ending normalization in send_http1_request only handles actual CR/LF characters:

val fixedContent = content.replace("\r", "").replace("\n", "\r\n")

This doesn't match the literal \r\n text, producing malformed HTTP like:

POST /doLogin HTTP/1.1\r\nHost: example.com\r\n\r\nuid=admin

...which is a single garbled line instead of properly delimited HTTP.

Strict servers (e.g. Apache-Coyote/Tomcat) reject this with 400 Bad Request, while lenient servers (Cloudflare, nginx) may tolerate it — making the bug intermittent and hard to diagnose.

Additionally, create_repeater_tab and send_to_intruder had no line-ending normalization at all, causing the same issue when requests were sent to Repeater/Intruder tabs.

Verification

Confirmed by sending identical raw content via netcat:

Format	Result
Proper CRLF (\x0D\x0A)	302 Found ✅
LF-only (\x0A)	302 Found ✅
Literal \r\n text	400 Bad Request ❌

Fix

Added a normalizeHttpContent() helper that handles both literal escape sequences and actual line endings, converting everything to proper HTTP CRLF:

private fun normalizeHttpContent(content: String): String = content
    .replace("\\r\\n", "\n")   // Literal \r\n escape sequences → LF
    .replace("\\n", "\n")      // Remaining literal \n → LF
    .replace("\\r", "")        // Remaining literal \r → remove
    .replace("\r", "")          // Actual CR → remove
    .replace("\n", "\r\n")      // All LF → proper CRLF

Applied to all three affected tools:

• send_http1_request — replaces the existing incomplete normalization
• create_repeater_tab — previously had no normalization
• send_to_intruder — previously had no normalization

Testing

• All existing tests pass (./gradlew build succeeds)
• Manually verified against Apache-Coyote server (demo.testfire.net) — requests now return proper responses instead of 400

Relates to #51

[dhawanmayank]

@danielgallen This should fix the issues: #51
Can you review?