feat: accept a CancellationToken in EmptyStreamingMarkdownFile

[Ryan VanderMeulen (rvandermeulen)]

Problem

EmptyStreamingMarkdownFile hardcodes MarkdownParser(flavour), so a streaming file always parses with CancellationToken.NonCancellable and an append cannot be aborted. It is the only remaining place in commonMain that constructs a MarkdownParser without a token: cancellation support (#141) and the streaming parser (#185) landed independently, and #203 threaded the token further into TopLevelBuilder.

This matters most when a block never closes. An unterminated fence keeps the whole document in unstableTail, so every append reparses all of it with no way to bail out. That is a common shape for LLM-generated markdown, which is the context this was found in: Firefox for Android renders streamed page summaries through this parser.

Approach

It was not clear what the project's policy on ABI compatibility is, beyond the // To keep the ABI compatibility. comments in MarkdownParser.kt, so the safer route was taken here.

Adding a second defaulted parameter to the existing function would drop the EmptyStreamingMarkdownFile$default(MarkdownFlavourDescriptor, int, Object) synthetic that no-argument Kotlin callers bind to, breaking anything compiled against 0.7.8. Instead the flavour-only function is unchanged and delegates to a new two-argument overload. Diffing compiled method sets against the published 0.7.8 jar confirms nothing removed and one method added.

The cost is an extra overload, plus the loss of EmptyStreamingMarkdownFile(cancellationToken = token), since the default flavour can no longer be combined with a token. Should an ABI break be acceptable, the single-function form seems preferable and can be substituted on request.

MarkdownParser, TreeBuilder, TopLevelBuilder and SequentialParserManager all deprecate their tokenless entry points. EmptyStreamingMarkdownFile(flavour) is left undeprecated here because the no-argument form is used throughout the existing test suite, but the deprecation can be added for consistency if preferred.

Tests

Added three new cases: cancellation propagating out of append, the token being consulted on successive appends while the unstable tail grows, and the flavour-only overload producing output identical to an explicit NonCancellable.

[Ilia Permiashkin (p3rmiashkin)]

Please update CHANGELOG.md

[Ryan VanderMeulen (rvandermeulen)]

Dropped flavourOnlyOverloadMatchesExplicitNonCancellable. The two remaining cases cover distinct behaviour: the token being consulted on successive appends while the unstable tail grows, and an exception from the token propagating out of append.

CHANGELOG.md was already updated in this PR: [#210] Accept a CancellationToken in EmptyStreamingMarkdownFile, at the top of ## [Unreleased]. Happy to reword or move it if something specific was intended there.