Record note and rule insertion as tracked changes so the redline can be rejected

[JSv4]

Closes #614.

What was actually wrong

The issue describes the citation as being wrapped in w:ins and the definition as staying behind. It is worth correcting the mechanism, because the next reader will otherwise go looking for a w:ins that was never there: InsertFootnote/InsertEndnote never consulted the recording mode at all. Both the body citation and the note definition were written as ordinary content, so rejectAllRevisions had nothing to reject — which is why the reproduction reports two residual revisions rather than one. Dumped from the real op before any change:

<w:p>
  <w:r><w:t>First</w:t></w:r>
  <w:r><w:rPr><w:rStyle w:val="FootnoteReference"/></w:rPr>
    <w:footnoteReference w:id="1"/></w:r>   <!-- no w:ins anywhere -->
  <w:r><w:t xml:space="preserve"> paragraph.</w:t></w:r>
</w:p>

The consequence the issue names is exactly right, and it is the bad one: the redline looks complete and only fails when somebody actually rejects it.

The encoding

The citation is the reversible unit and the definition follows it. Rejecting the w:ins carries the reference away, which leaves the definition uncited, and the note-lifecycle rule deletes it in the same resolve. Accepting unwraps the w:ins and both survive.

The definition deliberately carries no revision markup of its own. A second w:ins inside it would be a revision with no independently meaningful resolution: rejecting it while keeping the citation yields an empty note, and keeping it while rejecting the citation yields a note that is pruned anyway.

This is option 1 from the issue rather than the fail-closed fallback, because the mechanism it needs was already in the codebase — PruneOrphanedNotes, added for #516 and extended for #591 — and pointing the op at it costs less than refusing does.

One rule, one owner, and one place it was wrong

Internal/NoteReferenceOps.cs is now the single owner of a note definition exists exactly as long as something still cites it. Two callers:

• DocxSession, after a structural delete or a revision resolution, in both directions. Its previous private copy moved here unchanged in behaviour except for one thing — it scanned only word/document.xml for citations. A note cited from the body and a running header was therefore "referenced before, unreferenced after" when the body citation went away, and got deleted out from under the header. It now asks every story a note reference can legally live in. DS431 covers it.
• RevisionProcessor, on the reject path only. This is the gap that made the fix incomplete without it: DocxDiffOps.AcceptRevisions/RejectRevisions route to RevisionProcessor, and that is what npm, python, the MCP server and WASM call. Before this change the same redline was reversible through a DocxSession and not reversible through any of those transports.

Why reject only, and not accept. I tried it symmetrically first and it broke three DocxDiffScenarioTests cases, which turned out to be the right answer arriving as a test failure. Accept(Compare(l, r)) ≡ r is the comparison engine's documented contract, and the fixtures' counterpart documents legitimately carry a reference-less note definition — a naive paragraph deletion leaves one. Accept must reproduce the counterpart as the comparison saw it, husks included. Reject cannot hit that conflict: a note loses its citation on reject only when the redline introduced that citation, in which case the definition came in with the redline too. DocxSession applies the rule in both directions because an editor is authoring a document rather than inverting a comparison. DS429/DS430 pin the two contracts as distinct so a future symmetry cleanup fails loudly.

The audit the issue asked for

Every session op that writes package state under recording now falls in one of three rows, and docx_mutation_api.md carries the table:

Record as revisions	ReplaceText family, the delete family, InsertParagraph, SplitParagraph, MergeParagraphs, MoveBlock, the formatting ops, the table row/column ops, InsertHorizontalRule (fixed here), InsertFootnote/InsertEndnote (fixed here)
Refuse with tracked_operation_unsupported	InsertTable, ApplyListFormatRange, every image mutation
Apply untracked, by design	The running-story and document-setup ops (SetHeaderText, SetFooterText, InsertPageNumberField, SetPageNumbering, …). Word does not redline header/footer authoring either. Comments and annotations are likewise not revisions

Images were already fail-closed, so the issue's other named suspect was clean. InsertHorizontalRule was not: it wrote its paragraph untracked, so rejecting left the rule behind. It now takes the same MarkParagraphContentAndMark call InsertParagraph already makes. The documentation that claimed InsertParagraph does not track was simply stale and has been corrected.

Making header/footer authoring trackable is feature-sized and is not attempted here; the table says so plainly rather than leaving the reader to infer that the gap is closed.

Validation

Eight new test cases, all of which fail on main:

• DS366 (footnote and endnote) — author under recording, then resolve both ways. Reject leaves only Word's two reserved separator notes, no citation, and DocxDiff.GetRevisions(baseline, rejected) is empty, which is the property that actually matters. Accept keeps citation and definition with no w:ins left.
• DS367 — the diff engine still reports the insertion. The citation is a w:footnoteReference nested inside w:ins, a shape this op had never produced.
• DS368 — what proveRedlineReversibility reports, which is how the issue was found. The reject path still diverges in document.xml (the run the citation split), settings.xml and styles.xml — residue a generated redline legitimately explains — but /word/footnotes.xml is no longer among them. The assertion reads a populated divergence list, so it is not vacuously true.
• DS429/DS430 — the stateless transport path in both directions, pinning the asymmetry above.
• DS431 — a note cited from a header survives losing its body citation.
• DS224 — the horizontal rule is a revision, and rejecting it takes the paragraph back out.

Full suite: 4183 passed, 0 failed, 3 skipped. Warning baselines move by exactly one each (132 → 133 library, 775 → 776 tests) for the one new file, per the rule in CLAUDE.md; both numbers are updated in the same commit.

Note for whoever lands #615

That branch carries a guard asserting insert_footnote is not reversible under recording:

assert.notEqual(step.args?.action, 'insert_footnote', ...)

It is now stale. The demo can footnote the negotiated liability cap again if that reads better than the paragraph it was changed to.