refactor(painters/dom): drop list-item fragment renderer (SD-2851)

[luccas-harbour]

Summary

Removes the now-unreachable list-item fragment path from the DOM painter. List rendering already flows through the paragraph fragment path (the PM adapter no longer registers orderedList / bulletList handlers — list paragraphs go through paragraphToFlowBlocks() as ParagraphBlock with marker metadata), so the dedicated list-item renderer and its helpers were dead weight duplicating paragraph behavior.

What changed

In packages/layout-engine/painters/dom/src/renderer.ts:

• Removed renderListItemFragment and applyResolvedListItemWrapperFrame.
• Removed the LIST_MARKER_GAP constant and the stripListIndent helper.
• Removed list-item branches from fragmentKey, deriveBlockVersion, and the fragment-frame dispatch — list-item is now treated as unsupported (throws in fragmentKey and renderFragment).
• Simplified computeBetweenBorderFlags in features/paragraph-borders/group-analysis.ts to pair para fragments only.

Tests:

• Deleted renderer-known-divergences.test.ts (the file existed to track list-item parity bugs; obsolete now).
• Removed list-item-specific assertions and fixtures from between-borders.test.ts, renderer-dispatch.test.ts, and index.test.ts.
• Updated the doc comment in test-utils/normalize-line.ts to reflect the remaining contexts (body, table-cell).

Body↔table-cell justify wordSpacing parity that incidentally lived in the deleted divergence file is still covered by renderer-parity-contracts.test.ts:310-387. Lists rendered through the paragraph path are exercised by renderer-marker-suffix.test.ts, renderer-marker-textwidth.test.ts, and the multi-line list integration test at index.test.ts:1266.

What's intentionally NOT in this PR

The ListBlock / ListItemFragment types and their producers in contracts/, layout-bridge/, layout-resolved/, and pm-adapter/sdt/ are still present. They're now dead feeds (the painter rejects what they produce), but unwinding them touches multiple packages and is better as a follow-up so this PR stays focused on the painter cleanup.

Follow-ups

• Drop ListBlock, ListMeasure, and ListItemFragment from packages/layout-engine/contracts/src/index.ts and propagate the removal through layout-bridge (cache.ts, incrementalLayout.ts), layout-resolved (resolveLayout.ts, versionSignature.ts), and pm-adapter/sdt/.
• Continue with the next P0 items from RENDERING_DUPLICATION_AUDIT.md: extracting a shared paragraph content renderer that body and table-cell paths both consume.

[linear]

SD-2851

[chatgpt-codex-connector]

💡 Codex Review

superdoc/packages/layout-engine/painters/dom/src/renderer.ts

Line 3014 in a156110

throw new Error(`DomPainter: unsupported fragment kind ${(fragment as Fragment).kind}`);

Preserve list-item dispatch until all producers are removed

renderFragment now throws for any list-item fragment, but the list-item model is still produced elsewhere in the pipeline (layout-bridge/src/incrementalLayout.ts and layout-resolved/src/resolveLayout.ts still handle kind: 'list-item', and ListItemFragment remains in contracts). That means any remaining caller/flow that emits legacy list fragments will hard-fail painting at runtime instead of degrading gracefully, which is a behavior regression introduced by this commit.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[luccas-harbour]

💡 Codex Review

superdoc/packages/layout-engine/painters/dom/src/renderer.ts

Line 3014 in a156110

throw new Error(`DomPainter: unsupported fragment kind ${(fragment as Fragment).kind}`);

Preserve list-item dispatch until all producers are removed
renderFragment now throws for any list-item fragment, but the list-item model is still produced elsewhere in the pipeline (layout-bridge/src/incrementalLayout.ts and layout-resolved/src/resolveLayout.ts still handle kind: 'list-item', and ListItemFragment remains in contracts). That means any remaining caller/flow that emits legacy list fragments will hard-fail painting at runtime instead of degrading gracefully, which is a behavior regression introduced by this commit.

ℹ️ About Codex in GitHub

The pm-adapter does not produce ListBlocks, this has been the case ever since the unification of lists and paragraphs. A follow-up ticket should remove this from other layers of the layout-engine as well. Visual tests were run against all documents in the test-corpus and no changes were detected.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!