fix(super-editor): stop export from stripping tracked marks off the caller's tree

[leonidkuznetsov18]

What

Once a header (or footer) sub-editor exists, the first exportDocx() writes the part's imported w:ins/w:del correctly and every later export writes it with the tracked changes gone — text inside a w:del comes back as an ordinary run, so a counterparty's tracked deletion silently becomes accepted content on the second save, with no user edit involved (#3893).

Mechanism

The w:ins/w:del decoders (v3/handlers/w/ins/ins-translator.js, v3/handlers/w/del/del-translator.js) removed the tracked-change mark by assigning the filtered marks array back onto the node they were handed:

node.marks = marks.filter((m) => m.type !== 'trackInsert');

That node belongs to the caller. The body path never notices because it starts from a fresh getUpdatedJson() snapshot each export, but #exportProcessHeadersFooters passes the converter's persistent import-time tree (this.headers[id] / this.footers[id]) by reference once a sub-editor is registered — which happens as soon as a user clicks into the header. Export 1 strips the marks off that tree permanently; export 2 re-serializes the already-stripped tree.

Fix

Strip the mark on a shallow copy of the node instead ({ ...node, marks: filtered }), leaving the caller's tree intact. This fixes the root cause for every exportToXmlJson caller, including the header-footer-sync fallback path that also passes the persistent tree by reference — repeated exports with no intervening edit now produce the same tracked changes every time. These two assignments are the only in-place mutations of caller data on the export path (audited node.marks = / node.attrs = / splice sites in the decode chain).

Testing

• New integration regression: headerTrackedChangesDoubleExport.test.js with a synthetic fixture (header-tracked-changes.docx, derived from the in-tree header-alternating-odd-even.docx with one w:ins + one w:del spliced into word/header1.xml). It registers a header sub-editor the way HeaderFooterEditorManager does, exports twice, and asserts word/header1.xml still carries ins=1 del=1 on the second export. Red without the fix (second export drops to ins=0 del=0, exactly the issue's output), green with it.
• New unit tests in both translator suites assert decode leaves the caller's marks untouched while the stripped copy is what reaches exportSchemaToJson.
• Full import-export + super-converter suites: 3643/3643 pass.

Fixes #3893

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[cubic-dev-ai]

No issues found across 6 files

_{Re-trigger cubic}

[leonidkuznetsov18]

recheck

[caio-pizzol]

Thanks, Leonid, for the careful fix and regression tests. We confirmed that V2 preserves the header’s tracked insertions and deletions across repeated exports, including after opening the header, consistent with the resolution of #3893.

We’re focusing maintenance on V2, so we’re closing this V1-specific PR. For applications still using V1, please follow the V2 migration guide. We appreciate the work you put into isolating the mutation.