fix: keep the marker a task list item was authored with

[Azganoth]

Summary

A task list item is now written with the marker it was authored with: x or X for a
checked item, and a space or a tab for an unchecked one. GFM reads each pair as the same
state, so the state always survived a save and only the authored spelling was lost —
- [X] done came back - [x] done, and a tab between the brackets became a space.

The issue asked which of the two rows was reachable, since tabs are expanded to tab stops
during parsing and a read-time difference no serializer change reaches would have narrowed
this to the marker case. Both are reachable. The mdast item's position.start.offset
indexes the original source, so the slice the parse plugin reads carries the tab verbatim;
the expansion happens inside micromark's token stream and does not move the offsets the
tree reports.

leafdownListForm stamps the marker onto the mdast item the way it already stamps the
bullet, the number, and the padding, and list_item carries it as an attribute. It is read
off the whole slice standing between the item's own marker and the content it opens with,
rather than off the fixed-length head the other three use. GFM consumes the checkbox and
the whitespace after it, so that slice ends exactly where the marker does, and no bound
computed from the list marker and its padding covers every item: the widest is a nine-digit
ordered marker whose content opens on the line after it, indented past the marker's own
width.

A marker spells the state it was written for rather than decorating both, so an item the
editor moves to another state carries none and is written in the default form from then on,
including when it returns to the state it was authored in. That is the limit of the rule
#359 settled: a heading's closing sequence decorates a heading whatever its level, while a
task marker is the state it would otherwise decorate. Removing the checkbox is the same
move, so an item made a task item again is written in the default form too. The command
path and the checkbox-click path go through one helper because they make the same move.
docs/decisions.md records the boundary, because the rule under #359 read alone argues for
restoring the authored marker.

Related Issue

Closes #318

Verification

markdownCompatibility.test.ts gains a Task marker form group.

Nine rows assert the authored marker across a save and a reopen, covering both checked
spellings and both unchecked ones under padding, nesting, an ordered marker, a blockquote,
and an item whose content opens on the line after its marker. Each asserts the written
bytes and the reopened document together, because a marker written in a form the next read
does not answer for costs the state rather than the form, and the bytes alone cannot tell
the two apart.

Five more cover the editor's own moves, where the authored marker gives way: a command
checking or unchecking an item, a click on its checkbox, an item moved off its state and
back, an item that stops being a task item and is made one again, and one the editor
creates.

corpusRoundTrip.test.ts is unchanged and still passes; corpus/gfm/task-lists.md loses
both differences this issue names, which is the fourth Done when item.

Manually verified in Typora 1.14.9 on Windows 11:

1. Opened a file holding every case above and saved it with no edit. It came back
   byte-identical, so the authored marker is what the established editor in this category
   preserves as well.
2. Unchecked an item authored [X], saved, checked it again, saved. Typora writes [ ]
   and then [x], which is the rule this branch implements.

Not verified: Typora is not evidence for the unchecked pair. It does not read [<tab>] as
a checkbox at all, rendering literal brackets and preserving them as ordinary text. That
case rests on GFM instead, whose reference implementation accepts a tab explicitly to match
GitHub — micromark-extension-gfm-task-list-item uses markdownSpace, [\t ], with that
reason recorded beside it.

Notes

• corpus/gfm/task-lists.md stays on the convergence assertion rather than moving to byte
  identity. One difference remains and belongs to another class: [ ] not a list item is a
  lazy continuation, A lazy continuation line gains its block marker on save #322, and gains the explicit indentation the file left out.
• The malformed markers the issue puts out of scope — [], [y], and [x] with no
  following whitespace — are unaffected. GFM leaves them as ordinary list content, so the
  slice the marker is read from holds only the item's marker and padding and the pattern
  cannot match.
• Filed while measuring this change and left alone: A nine-digit ordered marker's four-space padding is dropped on save #369, where an item written with a
  nine-digit ordered marker and four spaces of padding comes back with one space. It is a
  boundary of the padding class A list's bullet marker is rewritten and its numbers renumbered on save #317 delivered, reproduces with no task marker involved,
  and is the one row of the manual Typora file that Leafdown still rewrites.