fix: stop truncating SSE field values containing U+2028/U+2029/U+0085

[lzcGeek]

What

SseLineSubscriber extracted data:, id: and event: values with MULTILINE regexes. The Java regex engine treats U+2028 (LINE SEPARATOR), U+2029 (PARAGRAPH SEPARATOR) and U+0085 (NEXT LINE) as line terminators, so ^data:(.+)$ matched only a prefix of any line containing one of those characters — and everything after it was silently discarded. The client then failed to deserialise the truncated JSON and threw McpTransportException: Error parsing JSON-RPC message.

This PR removes the three regexes and extracts field values per the SSE specification: the characters after the colon with a single leading space removed. The line splitter feeding the subscriber (fromLineSubscriber) only splits on \n, \r and \r\n, so those characters now arrive inside a line and are preserved intact.

Why

Fixes #1136. Any tool result, resource content or prompt text containing one of these characters — they are legal unescaped inside a JSON string, and they turn up in real content such as text pasted from word processors, web pages and PDFs — was unreadable by the client.

How it was checked

• New ResponseSubscribersTest asserts that a data: payload containing each of the three characters is preserved byte-for-byte, that a vertical tab still works, that only a single leading space is stripped per data line, and that multi-line data: accumulation plus id:/event: values containing those characters are captured intact.
• mvn -pl mcp-core verify passes, including the spring-javaformat validation.

Notes

• The per-line trim() was dropped together with the regex, matching the reporter's suggested fix: per the SSE spec only one leading space is stripped, so interior whitespace is no longer mangled. The existing whole-event trim() behaviour at dispatch is unchanged.
• Prepared with AI coding assistance and reviewed by @lzcGeek.

Fixes #1136