feat: add w:pPrChange translator for paragraph property tracked changes (SD-2417)

[luccas-harbour]

Summary

• Add a new w:pPrChange translator that encodes/decodes tracked changes on paragraph properties (author, date, id) along with the nested w:pPr containing the previous properties
• Register the translator as a child of w:pPr and in the global handler index
• Extract base pPr property translators into a shared module to avoid a circular dependency between pPr ↔ pPrChange

[linear]

SD-2417 Investigation: Structural tracked changes dropped on import and export

[github-actions]

Status: PASS

The w:pPrChange translator looks correct. All three attributes (w:id, w:author, w:date) match the spec exactly — correct names, correct types (w:id as integer, w:date as ST_DateTime string). The single child element w:pPr is the only valid child, and the translator handles that correctly.

One minor note: w:id is required by the spec (the document is non-conformant if omitted). The current decoder has an interesting behavior — if a change object has only { id, author, date } with no paragraphProperties, the decode returns undefined (as shown in the test at line ~145). That means a pPrChange with no prior paragraph properties (empty <w:pPr/>) won't round-trip cleanly. The spec explicitly allows an empty <w:pPr/> to mean "no prior properties existed." Whether that matters depends on whether this code path is exercised in practice, but it's worth noting for future work.

See https://ooxml.dev/spec?q=pPrChange for full spec details.

[luccas-harbour]

The current decoder has an interesting behavior — if a change object has only { id, author, date } with no paragraphProperties, the decode returns undefined (as shown in the test at line ~145). That means a pPrChange with no prior paragraph properties (empty <w:pPr/>) won't round-trip cleanly. The spec explicitly allows an empty <w:pPr/> to mean "no prior properties existed." Whether that matters depends on whether this code path is exercised in practice, but it's worth noting for future work.

This issue was fixed.

[caio-pizzol]

@luccas-harbour clean structure — sharing the base translators between pPr and pPrChange is a nice call.

one issue: when the original <w:pPr/> inside <w:pPrChange> is empty, it gets lost on round-trip. the decode guard you added works, but the encode side never feeds it — the key gets dropped for empty elements. tested with a Word file — the empty <w:pPr/> disappears after export.

pPrChange-empty-pPr.docx

also a minor DX thing and a pre-existing ordering note — details in inline comments.

tests look good. left a few comments.

[caio-pizzol]

when <w:pPr/> exists but is empty, pPrTranslator.encode() returns undefined here — so the paragraphProperties key never makes it into the result. later, when decoding back to XML, the guard at line 81 (hasParagraphProperties) can't fire because the key is missing. the empty <w:pPr/> is lost.

the spec says <w:pPr> is required inside <w:pPrChange> — even when empty it means "there were no previous properties." tested with a real Word file and confirmed the element disappears after export.

Suggested change

	let paragraphProperties = pPrNode ? pPrTranslator.encode({ ...params, nodes: [pPrNode] }) : undefined;
	let paragraphProperties = pPrNode ? (pPrTranslator.encode({ ...params, nodes: [pPrNode] }) ?? {}) : undefined;

[caio-pizzol]

not blocking, just a heads up: the spec expects sectPr before pPrChange inside <w:pPr>, but the exporter always puts sectPr last. so if a paragraph has both a section break and a tracked property change, they'll be in the wrong order. this predates your PR — the pattern was already there, it just didn't matter until pPrChange existed. rare in practice. maybe a follow-up ticket?

[caio-pizzol]

emitWhenAttributesOnly isn't used anywhere — the pPrChange translator handles this case with its own logic instead. worth removing so it doesn't sit here unused?