test(docx-compare): characterize inherited LibreOffice Reject cross-reference recalculation

[stevenobiajulu]

Characterize LibreOffice Reject cross-reference recalculation

Public SHA-pinned NVCA indemnification paragraph-deletion control: LibreOffice identity(original) displays Section 1(a) inside the following COMMENT paragraph, while actual Reject of the generated tracked comparison displays Section 1.(a).

This is inherited, not introduced by PR #980's paragraph/field repair: the same mismatch at character794 was dynamically reproduced using the clean detached baseline at 31b1d8fd2e9f0f285cc6167906ef6e2c9f220699, its separately built comparison package and workspace dependencies. The repair's saved reader output shows the identical mismatch. The following paragraph remains COMMENT; total paragraph count is151 on original/Reject and150 on revised/Accept. Accept's following-comment text/style/outline matches the revised source.

This looks like field-result recalculation, but the precise cause is not yet established; do not label it repaired or silently normalize punctuation to pass text equality.

• Minimize the public cross-reference/numbering input, preserving field instruction and cache differences.
• Compare identity, Accept and Reject on clean source, baseline output and current output.
• Separate cached-result text, evaluated field result, list numbering and paragraph formatting assertions.
• Determine whether emitted structure or LibreOffice recalculation causes the changed punctuation, then propose a bounded repair if appropriate.
• Keep Word unverified until measured; open-cleanly is not a projection oracle.

Local evidence (public-only, no document uploads): /private/tmp/safe-docx-lo-recovery/.peer-review/indemnification-baseline-reader-20260916.log, corresponding retained reader XMLs and indemnification-baseline-reader.ts. No private content was used.

Ref: PR #980, #941. Separate from note binding and terminal empty-paragraph cases.