git:20261009.2c03dcb to git:20261009.113be1e

+ Word nests one author's `<w:del>` inside another author's still-pending `<w:ins>` (`<w:ins A><w:r>…</w:r><w:del B><w:r><w:delText>…</w:delText></w:r></w:del></w:ins>`), and the mirror (`<w:ins>` inside `<w:del>`). The reader keeps the run's `trackedChange` as the INNERMOST wrapper (its `tcN` is what accept/reject targets) and records the enclosing chain in `TrackedChange.within` (see [ast/CLAUDE.md](../ast/CLAUDE.md)). **A run is visible in a view iff EVERY enclosing wrapper is visible in that view** — `accepted` hides `del`/`moveFrom`, `baseline` hides `ins`/`moveTo`, `current` shows all — because rejecting the outer insertion removes the nested deletion with it, and accepting the outer deletion removes the nested insertion. That is exactly what the reverse-pre-order `accept --all`/`reject --all` produces, so `read --baseline` ≡ `reject --all` and `read --accepted` ≡ `accept --all` (and `wc`/`find` agree). Classifying by the innermost wrapper alone showed the nested deletion's text in `--baseline`. The XML-side LENGTH/PLACEMENT walkers (`sumVisibleTextLength`/`isWrapperVisibleInView` in [find/replace-span.tsx](../find/replace-span.tsx), [find/replace-across.tsx](../find/replace-across.tsx) and [comments/markers.tsx](../comments/markers.tsx)) never descend a wrapper hidden in the view, so a wrapper nested inside a hidden one contributes nothing — the same rule, structurally; keep it that way. (Untracked, `rebuildAcrossBoundaries` in replace-span.tsx never splits a revision wrapper the span crosses (issue #16): an additive one is cut IN PLACE by recursing the same walker into its content — so a nested `<w:hyperlink>`/field/revision is sliced at the right offsets, the replacement lands where the span starts (inside the ins, credited to its author, as for a match wholly inside it), and no `w:id` is duplicated; a subtractive one stays whole. Known gap, tracked only: `splitWrapperAcrossSpan` does not recurse into a wrapper nested inside the wrapper it splits, so a `--track` span that crosses a nested `<w:hyperlink>`/`<w:ins>` inside a `<w:ins>` still slices at the wrong offsets — its post-half does get a FRESH id from the allocator.)

+ - `setEnabled(on)` — toggles `<w:trackChanges/>` in settings.xml; turning on materializes the part.

+ ## Word-level diff for `edit --text`

+ `applyFormattingPreservingEdit` is what `Edit.paragraph` falls through to when the spec is `--text` without override formatting flags and `--no-formatting` isn't set. It:

+ 4. **Re-emits runs** grouped by rPr: untracked path emits only kept + inserted tokens (inherited rPr from nearest matched neighbor); tracked path emits kept tokens as plain runs, inserts in `<w:ins>`, deletes in `<w:del>`. Pure pPr properties (`--style`, `--alignment`) apply in place via `applyParagraphOptionsInPlace`.

+ **Other authors' pending revisions are resolved, not kept (issue #17, interim).** The diff rebuilds runs from the visible text under the single-author model, so another author's `<w:ins>` becomes plain text (or, on the `--markdown` path, is dropped) and their `<w:del>` vanishes. Until the rebuild keeps them, the CLI warns on stderr (exit 0) whenever a content edit — whole-paragraph `text`/`markdown`/`runs` (single or `--batch`), a `pN-pM` range replace, or `code edit` — resolves pending revisions by an author other than the editor, and points at span edits (`replace`, `edit --at pN:S-E`), which keep them. `Edit.paragraph` returns the authors as `resolvedAuthors` (`Edit.range` returns the list): `watchPendingRevisions` ([pending-authors.ts](pending-authors.ts)) snapshots the other authors' `<w:ins>`/`<w:del>`/`<w:moveFrom>`/`<w:moveTo>`/`<w:pPrChange>` BEFORE the rebuild and reports the ones missing from the edited region AFTER it. Don't replace that with a prediction of what each path keeps — the `--text` diff carries text boxes and inline content controls through and keeps the pPr, while the markdown/runs replace drops the box and any pPrChange and, under tracking, keeps an existing `<w:del>` but drops every `<w:ins>`; only the before/after diff is right for all of them.

+ `replaceSpanInParagraph` (the engine behind `replace --track` and `edit --at pN:S-E --track`) has ONE early branch, dispatching to [core/find/replace-in-revision.tsx](../find/replace-in-revision.tsx). **The gate**: the replace is tracked, the span is non-empty, every overlapping run shares the same immediate parent, and that parent is a `<w:ins>` / `<w:moveTo>` sitting DIRECTLY under the paragraph. Everything else — untracked, empty spans, a span crossing the wrapper's edge, a wrapper nested in a hyperlink/smartTag/field, a match inside a `<w:del>` under `--current`/`--baseline` — stays on the general walkers, byte-for-byte as before. Inside the gate, `w:author` decides (exact string match): **the wrapper is split the way Word does it** — it keeps its `w:id` plus the text before the span and the editor's `<w:del>` of the cut nested inside it (a del-of-ins, so rejecting either author's revision restores the right text), the replacement rides the editor's own paragraph-level `<w:ins>`, and the content after the span rides a copy of the wrapper with a FRESH id from the shared allocator — unless that tail is pure markers (comment range end + reference run, bookmark end), which stay in the wrapper after the cut instead of minting an empty revision (`isPureMarker`). **The editor's own `<w:ins>` is rebuilt in place** (same id, same date, no `<w:del>`, no split) — the replacement is just more of that same insertion — but every ZERO-width child of the cut runs (note/comment reference, drawing, text-box anchor — `inlineMarkerWidth === 0`; a tab/break/sym the offsets counted as a character goes with the text) is kept (`cutRemnants`), range starts ahead of the replacement and the rest behind it, so nothing anchored on the replaced words vanishes and a comment that opened inside the cut brackets the new words. A `<w:moveTo>` is split even by its own author: moved text is relocated original text, not new words. `revN` pairing in `cli/track-changes/groups.ts` requires both halves to share an author, so the other author's head ins never pairs with the editor's nested del. The new path computes the wrapper's start offset from the siblings before it, where the general `rebuildContainer` starts its walk at the first OVERLAPPING run's offset — correct only when the match sits in the wrapper's first run, which is the "deleted the wrong words" half of the bug (the nested `<w:del>` in the issue is just what put the match in a later run; `rebuildContainer` now starts at the container's own start offset — `RunSlot.parentStart` — so an untracked match in a later run of a multi-run wrapper cuts the right words too (#16)). Nested non-run children (a third author's `<w:del>`, bookmarks) move WHOLE, counted at their view-visible length (a `<w:del>` is 0 wide in the accepted view), and are never wrapped in the new `<w:del>`: one inside the span keeps its place, so the cut is deleted as one `<w:del>` per contiguous run group. Known limitations, all deliberately left on the old paths: an insertion nested in a hyperlink still gets a bare run inside it; an empty span (`pN:S-S`) inserts a bare run inside the other author's wrapper; a span crossing out of the wrapper takes `rebuildAcrossBoundaries` (its post-half gets a fresh `w:id` since #16); a `--current` match inside another author's `<w:del>` still lands the replacement inside that deletion.