Line handler splits output on U+2028, U+2029, NEL (U+0085) and form feed, breaking NDJSON records that OutputDataReceived/ReadLine keep whole #133

What's wrong

LineOutputHandler ends a line on any of LF, CR, CRLF, NEL (U+0085), LS (U+2028), PS (U+2029) and form feed:

private static bool IsLineBreak(char c) => c is '\n' or '\u0085' or '
' or '
' or '\f';

(used from ProcessDataByLine, lines 139–144). This set came from the original data.ReplaceLineEndings() implementation and was carried over in da03a26 (#85) for compatibility with that code. However Process.OutputDataReceived, StreamReader.ReadLine and essentially every line-oriented tool treat only CR, LF and CRLF as line breaks. No test covers the extra characters.

Why it matters

Those characters are allowed raw inside JSON strings. JSON.stringify, jq -c and Python's json.dumps(..., ensure_ascii=False) all emit U+2028/U+2029 unescaped. So a tool that prints NDJSON (one object per line) gets its records cut in half, and a caller that parses each delivered line as JSON throws.

Reproduced on Linux, net10.0, at current main:

command: sh -c "printf '{\"a\":\"x<U+2028>y\"}\n{\"b\":\"p\fq\"}\n'"
LineOutputHandler      -> 4 lines: {"a":"x | y"} | {"b":"p | q"}
Process.OutputDataReceived -> 2 lines

Running with Encoding.Latin1 has the same effect: every 0x85 byte becomes U+0085 and ends the line.

Suggested fix / acceptance criteria

• Treat only CR, LF and CRLF as line terminators. This matches OutputDataReceived and ReadLine. Keep the existing split-CRLF and pending-CR handling (LineOutputHandler emits a spurious empty line when a CRLF line ending is split across two reads #85, LineOutputHandler holds back a line ending in a bare CR until more output arrives, so a "100%\r" progress line is delivered seconds late (OutputDataReceived delivers it at once) #128) unchanged.
• Add tests showing that output containing U+2028, U+2029, U+0085 and \f is delivered as a single line, including when the character falls on a chunk boundary.
• Note the change in the changelog, since anyone relying on FF or NEL splitting will see different behaviour.