fix(core): pin the parser's line-ending and blank-line boundaries

[kewang]

Closes #33.

The problem

parseTasks and the Kotlin TaskParser are one rule written in two languages, and each left two
boundary decisions to its runtime — where the two runtimes disagree, and case-mirrored unit tests
cannot notice, because both sides spell the rule the same way.

Line endings. Java's regex $ also matches before a trailing line terminator; JavaScript's does
not. A tasks.md leaving a bare \r at the end of a line therefore reported a different total in
IntelliJ than in Web and VS Code.

Blank lines. isBlank() and trim() === "" cover different whitespace, so an NBSP-only line
moved the continuation boundary on one side only. This one was found while verifying the first.

Neither side was right

Measured against the reference renderer (react-markdown + remark-gfm, the same reference the
existing folding tests compare to):

Source	Reference	Kotlin	TypeScript
- [x] a\r	1	1	0
- [x] a\r\r\n- [x] b	2	2	1
- [x] a\n- [x] b\r	2	2	1
- [x] a\r- [x] b	2	0	0

Blank-line candidate	Reference	Kotlin	TypeScript
U+00A0, U+FEFF, U+2007, U+202F	not blank	not blank	blank
U+001C	not blank	blank	not blank

CommonMark counts a lone \r as a line ending and counts only spaces and tabs as blank. Aligning
Kotlin down to TypeScript's answer — the fix the issue suggests — would have settled both on the
wrong result and left the last row of the first table broken on both sides.

What changed

• All three CommonMark line endings normalised to \n before the split, on both sides.
• An explicit [ \t] predicate does the blank test and the trims on both sides, replacing
  trim() === "" / isBlank() at four sites each.
• Kotlin's CHECKBOX_RE and SECTION_RE move to \z, matching what BLOCK_OPENER_RE already does.
  Not cosmetic: Java's $ also admits U+2028 / U+2029, which \z closes.
• Mirrored tests on both sides for every case, written with escape sequences rather than literal
  characters.

U+0085 stays divergent and is pinned by a test on each side rather than fixed — it is an ordinary
character to JS's . and a terminator to Java's, and closing it needs an identical negated class in
both engines' (.+), which is not worth the cost for a character with no natural source in a task
list.

Verification

Each new test was checked against a temporarily reverted implementation, since a test that passes on
the old code proves nothing: 5 turn red on the TypeScript side, 4 on the Kotlin side. The two sets
differ because each guards the direction the other runtime got wrong; the rest are regression
guards and the documented exception.

Gates: type-check, lint, npm test (207 + 24 + 60), ./gradlew test (40) — all green.

Note for whoever cuts the release

@spekjs/core changes observable output for files with CR line endings or exotic whitespace (nothing
in this repo — verified by scanning every .md for those characters). That warrants a minor bump,
not a patch.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HjHibWXs9MTLcVmewMXDrL