PowerPoint stores bullet font/size/color on `<a:pPr>` via
`<a:buFont>`/`<a:buSzPts>`/`<a:buClr>` so the marker glyph stays
consistent regardless of the run's font. Wafflebase ignored those
paragraph attributes, so `renderListMarker` had to inherit from
the first inline — and the Hangul fallback in the importer makes
that first inline vary across bullets within one text box.

In the Yorkie "캐즘 뛰어넘기" deck this surfaced on slide 2: bullets
1–3 begin with English ("April, 2019: ") so their first inline stays
on Arial, while bullet 4 starts with "Oct, 2022: Yorkie, 캐즘 뛰어넘기"
and gets Noto Sans KR. At the same 18 pt the Noto `●` is ~2x taller
than Arial's, so bullet 4's orange marker visibly dwarfs the others
even though every paragraph authors the same `<a:buSzPts val="1800"/>`.

Add an optional `Block.marker` field (`BlockMarker`) for authored
marker style, populate it from `<a:buFont>`/`<a:buSzPts>`/`<a:buClr>`
during PPTX import (only on list-items), and teach the docs marker
painter to prefer it per-axis, falling back to the first inline when
unset so existing DOCX-imported and native docs continue rendering
unchanged. Existing Yorkie documents need a re-import to pick up
the new field; new imports get correct markers automatically.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Self-review uncovered three downstream paths that ignored the new
optional Block.marker, leaving subtle gaps once it carries meaningful
data:

- scaleBlocks() scaled inline fontSize but left marker.fontSize alone,
  so a shrink-autofit text box would render the marker glyph at the
  authored 18pt while body text dropped to the fit scale — the inverse
  of the bug the previous commit fixed. The "Yorkie 캐즘" deck's body
  shape uses normAutofit, so this is reachable.
- getSelectedBlocks() enumerated cloned block metadata by field name
  and didn't copy marker, so a copy/paste round-trip silently dropped
  authored markers on the head and tail blocks (middle blocks were
  spread-cloned and survived).
- YorkieDocStore doesn't (de)serialize marker through Yorkie Tree node
  attributes. Today no docs feature authors marker style, so this is
  latent; document the gap on the Block.marker jsdoc so a future docs
  feature or DOCX round-trip doesn't lose data silently.

Also tightens the renderer's color fallback to `??` for axis-uniform
style (StoredColor has no falsy legal value).

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

The previous commit read paragraph-level <a:buFont>/<a:buSzPts>/<a:buClr>
into Block.marker, but live-imported decks still showed the marker
glyph drift. Root cause: the "Yorkie 캐즘" deck (and most PowerPoint
exports) inlines only <a:buSzPts>/<a:buChar> on the paragraph while
the marker typeface (<a:buFont typeface="Arial"/>) lives exclusively
in the master's <p:txStyles><p:bodyStyle>. The importer ignored that
slot, so marker.fontFamily stayed undefined and renderListMarker fell
back to inlines[0]'s font — drifting back to Noto Sans KR on the
Hangul-starting bullet 4.

Parse <p:txStyles> in the master importer into a slot × level map
(`TxStylesMarkers`), thread it through ParseSlideOptions and
SlideParseContext, look up the right slot inside buildTextElement from
the host shape's <p:ph type>, and merge the level default *under* the
paragraph's own marker so per-paragraph overrides still win per-axis.

With this change, all four bullets of slide 2 import as
`{ fontFamily: 'Arial', fontSize: 18, color: ... }`, matching what
PowerPoint and Google Slides render.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

Second-pass code review caught three small items on top of the master
inheritance fix:

- The task doc's "Out of scope" section claimed master/layout
  inheritance was deferred, but commit 3 of this PR landed master
  inheritance. Rewrite the section as a "Re-validated gap" that
  explains why the original assumption was wrong, and narrow the
  remaining out-of-scope to layout-placeholder bullet defaults plus
  <a:buSzPct>.
- Paste's middle-block clone in text-editor's pasteBlocks path was the
  only branch that didn't deep-copy Block.marker (head and tail blocks
  did). Mirror the spread treatment so mutations to a pasted block
  can't leak into the clipboard payload.
- Add a comment on placeholderTypeToTxStylesSlot's `big-number` /
  `caption` branches explaining they're Waffle-only placeholder kinds
  the importer never produces from PPTX today — kept for forward
  routing rather than dead code.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>

CodeRabbit caught a subtle aliasing bug in mergeMarkers: when one of
its inputs was undefined it returned the other one verbatim. Since the
`base` argument is the master-level `markerDefaults` map entry shared
across every paragraph that resolves to the same slot × level, a
downstream mutation on the resulting `Block.marker` (clearFormatting,
theme remap, persisted-snapshot round-trip, …) would silently corrupt
every other list item that inherits the same default.

Clone in the single-input branches too. Marginal alloc cost — one small
object per list paragraph — against a real correctness hazard. Regression
test asserts two paragraphs that share a master default end up with
distinct marker references and that mutating one doesn't bleed into the
other or into the shared default.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>