feat(pptx): resolve theme colour, and paint the ground it needs

[andiwand]

🤖 Generated with Claude Code

Follow-up to #746. The colour reading deferred there turned out to be worth
nothing on its own and actively harmful, so this does the version that works.

Why literal colour was not the change to make

a:srgbClr — the literal form — is barely used. Across the four pptx fixtures:

fixture	literal run colours	scheme (a:schemeClr)
Chapter 4 (the reported deck)	none	1066
style-various-1	2	–
tuesday_d6	331 black, 36 white	–
2025-09-11	none	–

Shipping literal-only would have done nothing for the deck that started this and
turned 36 tuesday_d6 runs invisible. Colour in a pptx means theme colour.

What this does

Resolves the theme. A slot (tx1, bg1, accent1, …) resolves along
slide → layout → master → theme: the theme's a:clrScheme holds the values, the
master's p:clrMap says which slot each name stands for, and ColorScheme is
the two folded together. Masters are shared, so one is read once, not once per
slide. This is the first time the module walks past the slide at all.

Paints the ground, because colour is unsafe without it. Text a deck puts on
a coloured master is white; on our white page it vanishes. So p:bg — from the
slide, else its layout, else its master — lands on a new
PageLayout::background_color, and a shape's p:spPr/a:solidFill on the frame.
The reported deck's footers are white on its red master and are now readable.

Along with: a:bodyPr/@anchor, a:lnSpc line height, a:spcBef/a:spcAft
(absolute a:spcPts only — the percent form is of the text size, which css
would resolve against the width), and @baseline sub/superscript.

The odf bug this uncovered

A frame is a plain <div>, so its fill has to be a background-color — the
fill: we were writing only ever reached the <svg> a shape carries, and was
inert on every frame. Painting it revealed that odf's draw:fill-color
cascades independently of draw:fill and outlives it: LibreOffice writes
<style:graphic-properties draw:fill-color="#729fcf" …/> with no draw:fill
anywhere, and boxes the file leaves blank were about to come out blue. Verified
against a LibreOffice render of odp/image-1.odp and odg/sample.odg — neither
paints those fills. The fill state now rides in the resolved colour's alpha.
That is what moves the odf files in the reference output: stale fills correctly
becoming transparent. odg/sample.odg renders pixel-identically before and
after.

What still does not match

Master and layout shape trees are not drawn. tuesday_d6.pptx puts its
white titles on a gradient-filled custGeom banner that lives in its master, so
those 36 runs stay unreadable — neither custom geometry, nor gradients, nor
master shape trees are modelled. This is the honest residual of the trade-off,
called out in presentation/AGENTS.md. Images and bullets are also still
missing.

Test data

Reference output regenerated; the pins move to:

• reference-output/odr-public → f211f75
• reference-output/odr-private → eacdb50

Full suite: 1194 passed, 6 skipped. 70 public / 153 private output files change
— pptx from the new styling, odf from the fill fix.