A point release after 20261016.1: a page keeps its own user_data when facing pages join it to
another page.
user_data survives facing pages. A host that loads a document as single-page
spreads, each with its own user_data (for example a layout_id per page), and turns facing
pages on, lost the right-hand page's data. Two pages joined into one spread kept only one
user_data, and saving as single pages then gave every right-hand page the left-hand page's.
Each page now keeps the data it came with, through joining, deleting, moving, the facing toggle,
undo, and saving and reopening, and a single-pages save gives each page its own back. A spread's
own user_data is unchanged.
typograph.get_page_user_data({ container_index, record_index }) returns
{ user_data, own }, so a host can read a right-hand page's data while it shares a spread.
typograph.set_page_user_data(page, data) gives a page data of its own, and null gives it
back its spread's. record_index: null reads or sets the spread's own. The setter is one undo
step, and the getter returns a copy.fix/TYP-922-page-user-data): Spread.page_user_data, one entry per page and
null for the spread's, the same shape as page colours (TYP-846). absorb_page(),
extract_record(), both single-page builders, copy(), the record loader and serialize_record()
carry it. A page record writes user_data only when the page has its own, and that data is an
object or nothing. Browser suite run_page_user_data_tests().Page.userData (#60, merged) in every service first
(ALLOW_EXTRA_ATTRIBUTES=false): the nine services' chore/TYP-922-bump-document-schema lock
bumps must be merged and deployed before this release. Until then a document whose page carries its
own user_data fails validation there.6150b41: TYP-922 (PR #190), on top of 4313af8. canvas-service pins the same commit.