[markdown] Enforce 999-character limit in _parseReferenceLinkLabel - #2765

Stop scanning and return null from LinkSyntax._parseReferenceLinkLabel as
soon as the number of raw characters inside [...] (parser.pos - start)
exceeds 999.

Why this change is necessary

When LinkSyntax.close finishes matching a [...] bracket pair and the
immediately following character is [ (a potential full reference link
[text][label]), it calls _parseReferenceLinkLabel(parser) to scan from the
opening [ to the matching ].

CommonMark 0.31.2 section 4.7 ("Link reference definitions") specifies:

A link label begins with a left bracket ([) and ends with the first right
bracket (]) that is not backslash-escaped. Between these brackets there
must be at least one character that is not a space, tab, or line ending. A
link label can have at most 999 characters inside the square brackets.

While LinkParser.parseLabel (used for [label]: /url definitions at the block
level) already checked the 999-character limit,
LinkSyntax._parseReferenceLinkLabel (used for [text][label] inline
references) had only a TODO comment and no length bound at all. This caused
two problems:

1. Spec non-compliance: Full reference links [text][label] with more than
   999 raw characters inside [label] were still accepted. For example, a
   label containing more than 999 characters due to long whitespace runs could
   collapse via normalizeLinkLabel to match a short [a b]: /url definition,
   evaluating to a link instead of plain text, and custom linkResolver /
   linkBuilder callbacks were invoked with labels exceeding 999 characters.
2. Unbounded scan and string work before rewind: On an input with a long or
   unclosed reference label such as '[a][${'a' * n}]' or '[a][${'a' * n}',
   _parseReferenceLinkLabel scanned all O(n) characters into buffer. When a
   closing ] was present, it allocated an O(n) label string, ran
   _entirelyWhitespacePattern.hasMatch(label), and passed label to
   _tryCreateReferenceLink / _resolveReferenceLink (which ran
   normalizeLinkLabel and .replaceAll across all O(n) characters), only for
   InlineParser._linkOrImage to rewind parser.pos to the opening [ of the
   label and re-parse the same n characters as normal inline text.

How this change works

In _parseReferenceLinkLabel, start records parser.pos at the first
character after the opening [. At the top of each while (true) iteration
(before checking char == $rbracket), parser.pos - start is the exact number
of raw source characters already consumed inside [...]. Checking
parser.pos - start rather than buffer.length is necessary because
_parseReferenceLinkLabel strips the backslash when writing \\ or \] to
buffer, whereas CommonMark counts raw characters inside [...] (including
both \ and the escaped character when char == $backslash advances
parser.pos twice).

• If a label has at most 999 raw characters inside [...] (including a
  2-character escape at offsets 997 and 998, as in '${'a' * 997}\\['), its
  closing ] is at parser.pos - start <= 999, which passes
  parser.pos - start > 999 and breaks on char == $rbracket.
• As soon as 1,000 raw characters have been consumed inside [...] (or 1,001
  when a 2-character \ escape starts at offset 998 or 999, as in
  '${'a' * 998}\\['), the next iteration begins with
  parser.pos - start >= 1000 and immediately returns null before checking
  char == $rbracket, bounding every reference label scan and buffer
  allocation to O(1).

Behavior change

A full reference link [text][label] whose label has more than 999 characters
is no longer resolved; it renders as literal text. CommonMark §4.7: "A link
label can have at most 999 characters inside the square brackets."
LinkParser already applied this limit to definitions; inline references did
not, so a 1,000-character label could match a definition whose label
normalizes to the same text, and custom linkResolvers were invoked with
unbounded labels.

Differential testing

Rendered every input with origin/main and with this branch (GFM extension
set, 30 s per-file timeout) and compared the HTML. Sources:

• pub.dev: 367,926 Markdown files from 93,452 packages
• Real-world docs: 116,231 files from mdn/content, github/docs,
  kubernetes/website, freeCodeCamp, tldr, flutter/website,
  dart-lang/site-www, microsoft/vscode-docs, withastro/docs,
  rust-lang/book, GitHub READMEs, and Wikipedia
• Parser test suites: 6,458 cases from cmark, cmark-gfm, commonmark.js,
  pulldown-cmark, md4c, goldmark, markdown-it, comrak, marked,
  pandoc, and pathological generators
• OSS-Fuzz: 57,716 inputs from the cmark, md4c, and markdown-it-py fuzzers

OSS-Fuzz inputs that sit at the 30 s timeout or the stack limit flip between
runs; every one reported as a new failure was re-run standalone on both trees.
Where the HTML changed, the changed region was also compared with the output of
commonmark.js 0.31 for the same input.

Results:

• No HTML differences in any source.
• 1 OSS-Fuzz timeout resolved; one 93 KB OSS-Fuzz input was reported as a new
  timeout — standalone it takes 5.4 s on main and 5.3 s on this branch (three runs each), so that was load during the run. Cumulative parse time −1.1%.