fix(painter-dom): set default page text color

[xy200303]

Summary

• Give DomPainter pages an explicit default text color of var(--sd-layout-page-color, #000).
• Allow consumers to override the page text color through pageStyles.color.
• Add tests covering the default and override behavior so list markers and other content without explicit run color do not inherit a hostile host-app color.

Verification

• pnpm test:all -- --root ./packages/layout-engine/painters/dom src/styles.test.ts
• git diff --check
• rg "@superdoc/(super-editor|style-engine|layout-bridge|layout-resolved)" packages/layout-engine/painters/dom/src -g '!*.test.ts' -g '!_test-utils.ts'
• pnpm test:all -- --root ./packages/layout-engine/painters/dom src/paragraph/list-marker.test.ts src/renderer-marker-suffix.test.ts src/renderer-marker-textwidth.test.ts (fails during collection: current workspace cannot resolve @superdoc/font-system)
• pnpm test:all -- --root ./packages/layout-engine/painters/dom src/index.test.ts -t "word-layout markers|resolved list" (fails during collection: current workspace cannot resolve @superdoc/font-system)

Closes #3456

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[caio-pizzol]

@xy200303 thanks for jumping in on this and for tracking down the invisible list marker issue.

I’m going to close this version because the fix is in the wrong place. This PR sets text color through page CSS. That can make the marker visible, but it does not match how Word stores default text color.

For a real “default text color” feature, we should update the document defaults in styles.xml, roughly like this:

styles.apply({
  target: { scope: 'docDefaults', channel: 'run' },
  patch: {
    color: { val: 'FF0000' },
  },
});

For the original invisible marker bug, we should fix the code that turns the Word file into rendered text. If the Word file has no text color set, SuperDoc should choose Word’s automatic text color, usually black on a white page, before rendering. Explicit colors from styles, numbering, or direct formatting should still win.

So the next version should avoid the CSS variable and move the fix into the document/style conversion path.