Fix LT-22351: load default font features in BaseStyleInfo.ProcessStyleRules

[johnml1135]

Summary

Font features set as a style's default font (not tied to a writing system) saved correctly but silently disappeared on reload — breaking Dictionary Preview CSS generation for anyone using default-level font features.

1. The bug that started it all

flowchart LR
    A["Styles dialog<br/>sets default font features"] --> B["Save<br/>GetOverridesString serializes fine"]
    B --> C[("Database<br/>style rules blob")]
    C --> D["Load<br/>ProcessStyleRules switch"]
    D -->|"no case for ktptFontVariations"| E["Dropped"]

Loading

BaseStyleInfo.ProcessStyleRules had a case for the default font name but none for default font features (ktptFontVariations), so it fell to default: break and the value was thrown away on load. The save path and the per-writing-system override path both already understood this property; only the default-font load path didn't.

2. Fixing it exposed a second, older bug

Take a parent style Title Main with an English override of Fontastic and a default font of Times New Roman. A child style Inherit Title is based on it, and the only thing set on the child is a default font feature: smcp=1. What does the child's English text render in?

	Before this PR	Fixed the obvious way (one-line)	This PR (final)
Default font features loaded?	No — no case in the switch	Yes	Yes
Does the child's default become "has explicit"?	No	Yes	Yes
What runs on the child's English override	nothing — the propagate branch never triggers	InheritAllProperties(default) — copies every default value, explicit or not	InheritExplicitProperties(default) — copies only values the default itself set explicitly
Resulting English font name	Fontastic ✅ (correct, by luck)	Times New Roman ❌ (clobbered)	Fontastic ✅ (correct, on purpose)
Resulting English font features	missing ❌	smcp=1 ✅	smcp=1 ✅

The middle column isn't hypothetical — it's what a one-line fix to just ProcessStyleRules would have produced, since fixing the load path is what makes IsAnyExplicit true and turns on the propagate-to-overrides branch for the first time for these styles.

Fix: only propagate default properties the style explicitly set, via new FontInfo.InheritExplicitProperties. Properties the default merely inherited from further up the style chain are left alone, so they no longer clobber an override's own, more specific inheritance.

3. The rule now, in plain terms

• Explicitly set default → propagates. If a style explicitly sets a default (font name, bold, features…), that value wins over whatever a based-on style's own writing-system override had. Intentional, longstanding behavior (LT-18109).
• Merely inherited default → hands off. If a style's default value for some property was never explicitly set — just riding along from the based-on style's default — it must not overwrite an override correctly inherited from the based-on style's own writing-system override.

4. A third, smaller bug found along the way: bullet fonts

BulletInfo.DecodeFontInfo stopped reading an encoded blob after the first string property, so a bullet with both a custom font name and font features lost the features on decode:

Encoded property (in order)	Before (break)	Now (continue)
ktptFontFamily = "Algerian"	read	read
ktptFontVariations = "smcp=1,ss01=2"	never reached — loop exits	read

One-character fix: break → continue.

Tests

• Default font features round-trip through save/load.
• The clobber, pinned failing-before / passing-after.
• Explicit defaults still correctly propagate to overrides (LT-18109 behavior preserved).
• Explicit default font name still wins across writing systems.
• Bullet font decode round-trips both font name and features.

Full suite green on net462 and net8.0 (SIL.LCModel.Tests 1706/1706, SIL.LCModel.Core.Tests 787/787, SIL.LCModel.Utils.Tests 302 passed/2 skipped, SIL.LCModel.FixData.Tests 21/21) — no regressions.

References JIRA LT-22351. A companion FieldWorks PR (#1005) will consume this liblcm fix once merged and released.

🤖 Generated with Claude Code

---

This change is

[johnml1135]

Companion FieldWorks PR consuming this fix: sillsdev/FieldWorks#1005 (draft, pending a liblcm release containing this change).

[johnml1135]

Regarding the question of whether the original one-line load fix was preferable to the follow-up inheritance change: the PR description now has a dedicated subsection, "Why the inheritance change is needed (v1 vs v2)", laying out the evidence -- including why the one-line fix alone regresses ws-override inheritance for styles whose only style-level setting is font features, how the change preserves the intent of the original LT-18109 commit (113a768), and the alternative that was considered and rejected.

Commit 66eda1b adds two tests that pin the LT-18109 semantics under the new code (explicit defaults propagate into ws overrides, and an explicit default font name wins over the parent's ws override); both pass with no further production change, and the full suite is green on net462 and net8.0.

[jasonleenaylor]

Make sure that we squash with a clean and concise commit comment describing the 3 different changes in appropriate detail.

@jasonleenaylor reviewed 6 files and all commit messages, and made 1 comment.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on johnml1135).