Fix: KeywordHelp parser tolerant of LF / CR / CRLF line endings

[mtinti]

Proposed Change

Rdmp.Core/Repositories/Managers/CommentStoreWithKeywords.cs splits KeywordHelp.txt on Environment.NewLine. On Windows runtime that's "\r\n", but the embedded resource carries whatever line-endings the build host stored the file with — typically LF on Linux/macOS checkouts. A binary produced via dotnet publish -r win-x64 --self-contained true from macOS crashes on first launch on Windows with:

Fail  Malformed line in Resources.KeywordHelp, line is:
<entire concatenated file>
We expected it to have exactly one colon in it

Fix: split on {'\r', '\n'} with StringSplitOptions.RemoveEmptyEntries so the parser tolerates any line-ending convention regardless of which host produced the embedded resource:

- var lines = keywordHelpFileContents.Split(new[] { Environment.NewLine }, StringSplitOptions.RemoveEmptyEntries);
+ var lines = keywordHelpFileContents.Split(new[] { '\r', '\n' }, StringSplitOptions.RemoveEmptyEntries);

This is the same pattern Rdmp.Core/MapsDirectlyToDatabaseTable/Versioning/Patch.cs:50, 90 already uses for parsing its embedded SQL header lines — bringing the one straggler into line with the existing codebase convention. RemoveEmptyEntries collapses the spurious empty between '\r' and '\n' on CRLF inputs, so all three conventions produce identical output.

Audit — every site combining Environment.NewLine with embedded text resources

Reader	Behaviour	Risk
CommentStoreWithKeywords.cs	Splits KeywordHelp.txt line-by-line	Fixed here
Patch.cs:50, 90	Splits SQL header lines on {'\r','\n'}	Already correct
Patcher.cs:79, 115	ReadToEnd() only; no line splitting	None
UsefulStuff.cs:337 (SprayFile)	Byte-level Stream.CopyTo	None
License.cs:55	ReadToEnd() for display + SHA512 of bytes	None
ScintillaTextEditorFactory.cs:120, 122	.dic/.aff handed to Scintilla	Third-party owns parsing

The only EmbeddedResource .txt declared in any project is Curation/KeywordHelp.txt — exactly the file this fix targets.

Companion PR

The contributor walkthrough that surfaces this cross-compile path lives in PR #2334 (docs/mac-test-env). The two PRs are independently mergeable but produce a complete macOS contributor workflow when both land.

Type of change

• Bugfix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that would cause existing functionality to not work as expected)
• Documentation-Only Update
• Other (if none of the other choices apply)

Checklist

By opening this PR, I confirm that I have:

• Ensured that the PR branch is in sync with the target branch (i.e. it is automatically merge-able) — rebased onto latest origin/develop (a53edfd24).
• Created or updated any tests if relevant — the fix is exercised through CommentStoreWithKeywords during normal startup, which runs in every existing integration test path. Happy to add a focused unit test for AddToHelp that asserts CRLF / LF / CR inputs each produce the same key list, if maintainers prefer.
• Have validated this change against the Test Plan. The fix was verified end-to-end on the exact cross-compilation path the bug surfaces on: produced a self-contained Windows binary on macOS via dotnet publish -r win-x64 --self-contained true, transferred it to a real Windows machine, and launched it there. Without the fix the .exe crashes at startup with the "Malformed line in Resources.KeywordHelp" error quoted above; with the fix it launches normally and reaches the home screen.
• Requested a review by one of the repository maintainers
• Have written new documentation or updated existing documentation to detail any new or updated functionality and how to use it — companion PR Add Documentation/MacTestEnv/ — macOS contributor dev/test environment #2334 adds a contributor walkthrough that documents this cross-compile path.
• Have added an entry into the changelog — happy to add a "Developer experience" entry if preferred; the change is not user-visible on supported (Windows) builds.