Scale Rich Text message typography with the Text Size setting

[Recluse]

Problem

Rich Text / Extended Markdown messages ignore Settings → Appearance → Text Size.

ChatMessageRichDataBubbleContentNode builds its InstantPageTextCategories from nine
hardcoded point sizes:

category	kicker	header	subheader	paragraph	caption	credit	table	article	codeBlock
size	15	19	18	17	15	13	15	18	14

None of them consults the user's setting, while an ordinary bubble uses
ChatPresentationData.messageFont, i.e. Font.regular(fontSize.baseDisplaySize).

baseDisplaySize runs 14 / 15 / 16 / 17 / 19 / 23 / 26 for .extraSmall … .extraLargeX2.
The .regular step is 17pt — exactly the hardcoded paragraph size — so the two paths agree
there and diverge everywhere else. At the smallest step an ordinary message renders at 14pt
next to rich text still at 17pt in the same chat; at the largest steps the mismatch runs the
other way, with ordinary text at 26pt and rich text unchanged.

The show more link for truncated rich text is fixed at Font.regular(17.0) for the same
reason.

Change

InstantPageTheme already exposes the right tool:

public func withUpdatedFontStyles(sizeMultiplier:lineSpacingFactor:forceSerif:) -> InstantPageTheme

so the bubble theme is scaled by baseDisplaySize / 17.0 rather than growing a second set of
size constants. lineSpacingFactor: 1.0 is passed because the helper multiplies rather than
replaces it, preserving the per-category factors (0.685 for headings, 1.0 for body), and
forceSerif: false preserves the sans/serif split the theme already declares.

Three call sites:

1. the page theme is scaled through the helper;
2. Font.regular(17.0) on the show more link becomes the user's base size;
3. baseFontSize joins the currentPageLayout cache key.

Point 3 matters: that key holds the bounding width, the theme object identity, expanded
details, message stable version, pending edit key, page key and the show-more flag, but no font
size. Once the theme depends on the font size, a Text Size change that does not also replace
the PresentationTheme object would otherwise reuse a stale layout.

Testing

baseDisplaySize → resulting sizes, against the constants being replaced:

step	kicker	header	subheader	paragraph	caption	credit	table	article	codeBlock
14	12	15	14	14	12	10	12	14	11
17 (.regular)	15	19	18	17	15	13	15	18	14
26	22	29	27	26	22	19	22	27	21

At the .regular step the multiplier is 17/17 = 1, so that row is identical to the current
constants and rendering there is unchanged. Note that the shipped default is
useSystemFont: true, so which step a given user is actually on comes from the iOS Dynamic
Type body size via PresentationFontSize(systemFontSize:), not from a stored .regular.

At the smallest step subheader and paragraph both land on 14pt, because
withUpdatedFontStyles floors the scaled size. That is the helper's existing rounding, shared
with the full-screen Instant Page theme factory, so this change does not introduce a new
rounding policy — but if you would rather keep subheadings distinct at that step, that is the
place to adjust.

Not addressed

InstantPageV2Layout.swift pushes a fixed .fontSize(15.0) onto the style stack in
layoutCodeBlock and in layoutQuoteText, immediately after setupStyleStack has applied the
theme. So after this change the following still do not scale:

• code blocks;
• pull quotes;
• block quotes that take the single-paragraph fast path in layoutBlockQuote.

Block quotes with more than one child block do not take that path and scale normally, so the
inconsistency is only within the quote family. That file is shared with the other InstantPage
V2 consumers, so the right treatment there seemed like a maintainer decision rather than
something to fold into this change.

[CLAassistant]

All committers have signed the CLA.