feat(input): parse and serialize lists (lists 3/5)

[wildseansy]

The list stack (per the review ask, now including ordered lists — the shared machinery made them cheap to add):

1. refactor(input): generalize empty-line anchor machinery beyond headings (lists 1/5) #510 — anchor machinery refactor (no behavior change)
2. feat(input): list block types + marker rendering (lists 2/5) #511 — list block types + marker rendering
3. feat(input): parse and serialize lists (lists 3/5) #512 — parser + serializer
4. feat(input): list commands, keyboard editing, and empty-item anchors (lists 4/5) #513 — commands + keyboard + ZWSP/empty anchors
5. feat(input): list state, toolbar, docs, and e2e (lists 5/5) #514 — state + toolbar + docs + e2e

GitHub can't base a fork PR on another fork branch, so every PR targets main and the diff shown for PR N is cumulative — this PR's own change is its last commit (each stage is exactly one commit on the previous branch). We'll merge bottom-up; after each merge the next PR's diff collapses to just its own commit. Checkout feat/list-5-state to test the full feature end-to-end.

This PR (last commit)

Parsers map list items to their block type with depth derived from AST UL/OL nesting (never from counting leading spaces); iOS tags MD_BLOCK_LI itself since md4c emits inner paragraphs only for loose lists, and clips each item's range to its own first line so nested items keep their own depth.

Serializers emit - / computed N. via the handler's line prefix, indented a uniform three spaces per depth so ordered and bullet nesting round-trip in any combination. An empty item's line serializes bare: a marker-only line ( -) re-parses as a setext-heading underline for the previous line. Ordered markers always use computed ordinals, so a pasted 5. start value normalizes to 1. — noted in the docs.

Easy to verify with round-trips: 1. alpha\n 1. beta\n2. gamma ↔ editor.

🤖 Generated with Claude Code

[wildseansy]

Note on ordered-list start numbers (future extension point):

Both parsers in this PR normalize ordered lists to start at 1 — the store recomputes each item's ordinal from its adjacent same-depth siblings, so an imported 5. first item serializes back as 1. first item. This matches the existing renderer behavior (BlockStyleContext counts from 1 and the AST doesn't carry md4c's MD_BLOCK_OL_DETAIL.start), so the editor and EnrichedMarkdownText agree with each other, but both diverge from CommonMark, which honors the start number.

Flagging it here because of react-native-streamdown: LLM output routinely contains continuation lists (6. ... mid-response or lists split across chunks), and today those render as 1.. If start-number support lands library-wide someday, this PR's machinery is the natural seam — plumb MD_BLOCK_OL_DETAIL.start through the parsers and seed the store's per-depth ordinal counters with it instead of 1. No change proposed for this stack; just documenting the extension point.