fix(muya): preserve ordered list source markers - #4776

Thanks for the fix — the core intent is right and the no-edit open→save round-trip is correct and well-tested. I found one save-time crash that should block merge, plus a couple of edit-time numbering inconsistencies that stem from a single design choice, and two small cleanups.

1. Blocker — dfm list indentation throws RangeError on save

packages/muya/src/state/stateToMarkdown.ts:574 — the new preservedMarker branch sets itemMarker directly and skips the n > 99 → n = 1 clamp that previously bounded marker width in dfm mode. Downstream, the unchanged line

listIndent = ' '.repeat(4 - itemMarker.length) // stateToMarkdown.ts:610

then receives a negative count.

dfm is a shipping user preference (prefComponents/markdown/config.ts → value: 'dfm', main/preferences/schema.json enum). Repro: set Preferences → Markdown → List indentation → DFM, then open/save any ordered list that contains an item numbered ≥ 100 (a 100+ item numbered list, or one authored like 100.):

100. one
101. two

→ RangeError: Invalid count value: -1, and save/getMarkdown throws. On develop the clamp reset those to 1., so it never threw. Confirmed locally by running the PR serializer on this input in dfm mode (throws) vs develop (does not).

Fix: apply the same width clamp to the preserved-marker path, or floor the repeat count at 0.

2. Middle-insert emits a duplicate ordered marker

packages/muya/src/state/stateToMarkdown.ts:583 (with packages/muya/src/block/content/paragraphContent/index.ts:499) — editor-created items have no meta.orderMarker, so they fall back to listInfo.start, which collides with the number a following preserved item still carries.

Repro: open 1. one / 2. two, put the caret at the end of "one" and press Enter. The Enter handler creates { name: 'list-item', children: [] } (no meta), so save produces:

1. one
2.
2. two

Two 2. markers, where develop renumbered cleanly to 1. / 2. / 3.. For the source-oriented workflows this PR targets, that reintroduces exactly the kind of avoidable diff it aims to remove.

3. Deleting the first item desyncs the displayed number from the saved source

packages/muya/src/state/stateToMarkdown.ts:571 vs order-list.meta.start — nothing recomputes order-list.meta.start (which drives <ol start=…>), while the serializer now emits each surviving item's preserved marker.

Repro: open 5. a / 6. b (editor shows 5, 6), delete "a" → the editor still shows the survivor as "5", but save writes 6. b; reopening parses start=6 and it now displays "6". Same root cause as #2. (Serialization half confirmed locally; the display half is inferred from the <ol start> rendering.)

Root cause tying #2 and #3 together

The marker is stored redundantly on each item while start/delimiter already live on the list — two sources of truth for the same fact. Per-item markers freeze at parse time and never participate in renumbering, so any structural edit (insert / delete / reorder) drifts. Worth considering whether preservation belongs at list granularity instead — e.g. a "preserve authored numbering" flag on order-list.meta that suppresses renumbering — which would make both #2 and #3 disappear.

4. Minor — duplicated listInfo.start++

packages/muya/src/state/stateToMarkdown.ts:576 and :583 increment identically; the counter advances once per ordered item regardless of branch. Compute only itemMarker in each arm and increment once after the if/else.

5. Minor — non-idiomatic meta clone

packages/muya/src/block/commonMark/listItem/index.ts:19,44,56 — every sibling block assigns this.meta = meta by reference in the constructor and clones inline with meta: { ...this.meta } in getState (see codeBlock, taskList, table/cell). Since orderMarker is a string there's no aliasing risk to guard against, so create can do listItem.meta = state.meta and getState can inline the spread, dropping the _cloneMeta helper.

The round-trip fix itself is correct; #1 is the merge blocker, #2/#3 are the design decision to settle, and #4/#5 are optional.

Thanks for the detailed review. I pushed an update addressing these points.

For the _cloneMeta comment: agreed, I dropped the static helper and switched listItem back to the same style used
by sibling blocks: assign state.meta on create and inline-spread it in getState().

For the serializer issues: I changed the preservation model so source markers are only used for an unchanged parsed
ordered-list structure. markdownToState now stores the parsed item marker sequence on order- list.meta.sourceMarkers, and stateToMarkdown only preserves those markers when the current children still match
that original marker sequence. Once the list structure changes, e.g. insert/delete/reorder, serialization falls back
to meta.start + delimiter, so we avoid the mixed preserved/generated numbering drift.

This should address:

• DFM crash: repeat() is now guarded with Math.max(0, 4 - itemMarker.length), so 100. / 101. no longer throws.
• Middle insert duplicate marker: inserting a new item invalidates the source-marker signature, so the list renumbers
  as 1. / 2. / 3..
• Delete-first desync: deleting an item also invalidates preservation, so saved markdown follows the list start
  value instead of a stale per-item marker.
• Duplicate listInfo.start++: now incremented once after marker selection.
• Non-idiomatic clone helper: removed.

I also added regression coverage for the DFM 100. case, middle insert, delete-first, unchanged repeated markers, and
the block-level round-trip path.

Thanks for the rework — the fallback model fixes all five points from the first review. I pushed a few follow-up commits directly to the branch so this can land without another round trip:

• Merge develop — the branch was ~2.5 months behind; CI now runs against the current base.
• test(muya): rebuild the ordered list from its blocks in the marker test — the previous block-level case read muya.getMarkdown() right after boot. That serializes the parsed JSON state and never calls ListItem.getState(), so it stayed green with the item meta removed. The test now replaces the list with its clone first, which is the path loose-list toggling and indenting take; it fails if ListItem.getState() drops meta.
• refactor(muya): read the ordered item marker where list tokens are split — compatibleTaskList already matches each ordered item's marker to get the delimiter, so it now records item.orderMarker there, replacing the second regex and the three helper methods in markdownToState. Parsed states are identical to before.
• refactor(muya): assign the order-list meta like the other list blocks — JSONState.getState() and the serializer already deep-clone, and nothing mutates sourceMarkers in place, so OrderList goes back to holding its meta by reference like BulletList / TaskList.
• refactor(muya): consume preserved markers from the cloned list meta — instead of the preserveOrderMarkers flag and an index that mirrored start, the serializer drops sourceMarkers from its per-list meta clone when the list no longer matches, and shifts one marker per item. Output is unchanged.
• test(muya): ignore parsed ordered markers when comparing state across reopen — two specs added on develop since this PR opened ([Bug] Shift+Tab on a nested task list item puts a task item inside the parent bullet list #5341, [Bug] Tab on a list item appends it to the previous item's sublist even when that sublist holds the other item kind #5349) assert that the state after Tab/Shift+Tab equals the state reparsed from the saved markdown. After an edit, sourceMarkers / orderMarker still describe the list as parsed, while reopening parses fresh ones, so those specs now compare structure without the marker hints (the markdown must still round-trip unchanged).

Scope stays as you implemented it: authored markers are kept only while a parsed list is structurally unchanged, and any insert/delete/reorder renumbers from start.