DocComment text containing U+2028, U+2029 or U+0085 renders code that doesn't compile #129

What's wrong

DocComment.SplitLines (CodeBlocker/Templates/DocComment.cs:215-216) only splits on \r\n, \r and \n:

private static string[] SplitLines(string text) =>
	text.Replace("\r\n", "\n").Replace('\r', '\n').Split('\n');

The C# compiler also treats NEL (U+0085), LINE SEPARATOR (U+2028) and PARAGRAPH SEPARATOR (U+2029) as line terminators. When doc text contains one of those, everything after it is no longer inside the /// comment and gets parsed as code.

Failure scenario

Summary = "Line one Line two" on a method renders as

/// <summary>Line one<U+2028>Line two</summary>

Compiling the generated file fails on that line with CS1570 plus CS1001/CS1003/CS1026/CS1002, because Line two</summary> is read as source. U+2028 turns up regularly in text pasted from web pages or carried in JSON, which is exactly where generated doc summaries tend to come from.

TemplateRendering.QuoteStringLiteral (TemplateRendering.cs:117) already escapes U+2028/U+2029 for this exact reason, so string literals are safe but doc comments aren't.

Suggested fix

Treat \u0085, and as line breaks in SplitLines (normalise them to \n alongside \r), so each one starts a new /// line. Add a test that renders a summary containing each character and asserts every output line starts with ///.