A point release after 20261016.2: a page's own user_data stays on its page when a spread is
saved as single pages, and POD settings can replace a font family with a theme's font.
user_data on the page. 20261016.2 kept a
page's data through facing pages, but a save as single pages (single_pages, and save mode
single_pages_keep_together) moved it to the page's new spread and left the page itself
without it. A host that reads user_data from the pages got none on any page of a spread that
was split, while single pages and spreads kept together had theirs. Each page now carries its
own data on itself as well as on its spread. Data a page states as its own also stays its own
when it is the same as its spread's.fix/TYP-922-record-user-data): copy_user_data_to() gives the new
single-page spread the page's own data at both levels, the spread's user_data and the page
record's. absorb_page() keeps data a page stated as its own even when it equals the container's,
as page_fills does. Browser suite run_page_user_data_tests(), now with the record-level case
opened through the loader and saved with true and 'keep_together'.feat/TYP-923-replace-fonts): the Replace fonts column of PodSettingsDialog.
The rules are in fonthandles.ts: replacement_targets() lists the loaded fonts with a uuid, a
theme handle first; replacement_source() picks the uuid to replace from, never the default
sentinel; and plan_replacements() builds the substitute_font() calls. OK runs them before the
handles are assigned. A row whose target family is itself being replaced in the same OK is refused,
because the calls would chain through the uuid. A handle typed for a family that was replaced is
reported, not dropped. Vitest fonthandles.test.ts.Page.userData and the services' bumps shipped with 20261016.2.661b89e: TYP-922 (PR #191), on top of 6150b41. canvas-service pins the same commit.