test(git-sync): accurate null-edge docstring + fill round placeholder (F2/F3)

F2: the real-git modify/delete null-edge test docstring overclaimed it
caught loss of the `?? theirs` fallback end-to-end. git itself leaves
theirs in the working tree (stage 3) so commitMerge's `git add -A` would
stage it even with the bug — the assertions pass on broken logic. Reword
to state it verifies the clean-merge happy path; the real F1 regression
guard lives in the fake-fs apply-pull-actions.test.ts.

F3: fill the `round-?` placeholder with `round-2` in both new blocks to
match the file convention (header: 'QA #119 round-2').

Comment-only; no production or test-logic changes.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

packages/git-sync/test/apply-pull-actions.test.ts

@@ -496,7 +496,7 @@ describe('applyPullActions — merge result is surfaced, not swallowed', () => {
     expect(g.git.commitMerge).toHaveBeenCalledTimes(1);
   });
 
-  // NULL-EDGE coverage (round-? review F1): the genuine-conflict branch resolves
+  // NULL-EDGE coverage (round-2 review F1): the genuine-conflict branch resolves
   // to `ours ?? theirs`. The two cases where a stage is ABSENT are the
   // data-preservation core on the published `main` and were previously untested.
   it('NULL-EDGE modify/delete (ours absent): keeps THEIRS so the surviving edit is not dropped', async () => {

packages/git-sync/test/pull-conflict-normalize.test.ts

@@ -198,14 +198,22 @@ describe('pull merge — spurious vs genuine conflict (real git)', () => {
   });
 
   // ===========================================================================
-  // NULL-EDGE coverage (round-? review F1): the genuine-conflict resolution is
+  // NULL-EDGE coverage (round-2 review F1): in production the genuine-conflict
-  // `resolved = ours ?? theirs`. The two cases where a merge stage is ABSENT are
+  // resolution is `resolved = ours ?? theirs`. The two cases where a merge stage
-  // the data-preservation core on the published `main` and were untested — the
+  // is ABSENT (modify/delete, delete/delete) drive that null branch; the existing
-  // existing cases above only feed conflicts where BOTH sides are non-null.
+  // cases above only feed conflicts where BOTH sides are non-null. These tests
-  //   (i)  modify/delete (stage 2 absent) -> keep THEIRS (don't drop content)
+  // build REAL 3-way index stages and run the production path against an actual
-  //   (ii) delete/delete (stages 2 AND 3 absent) -> write nothing; stage the delete
+  // git repo — but be precise about WHAT they verify:
-  // These build REAL 3-way index stages (not fakes) so the production code path
+  //   (i)  modify/delete (stage 2 absent) -> the auto-resolve produces a clean,
-  // is exercised end-to-end against git itself.
+  //        marker-free body on `main` that still contains THEIRS. Caveat: this is
+  //        a HAPPY-PATH assertion, NOT an F1 regression-guard. For modify/delete,
+  //        git already leaves theirs in the working tree (stage 3), so commitMerge's
+  //        `git add -A` would stage it even if production dropped the `?? theirs`
+  //        fallback — the assertions below would still pass on the broken logic.
+  //        The guard that actually fails without `?? theirs` is the fake-fs unit
+  //        test in apply-pull-actions.test.ts, which records ONLY production writes.
+  //   (ii) delete/delete (stages 2 AND 3 absent) -> nothing is written and the
+  //        deletion is staged (this real-git case is a valid guard on its own).
 
   it('NULL-EDGE modify/delete (real git): our side DELETED, their side MODIFIED -> keeps THEIRS, clean on main', async () => {
     if (!available) return;
@@ -240,8 +248,10 @@ describe('pull merge — spurious vs genuine conflict (real git)', () => {
     expect(res.conflictedPaths).toEqual([file]);
     expect(await git.isMergeInProgress()).toBe(false);
 
-    // CONTENT PRESERVED: `ours` is null (we deleted) so `ours ?? theirs` keeps the
+    // CONTENT PRESERVED on `main`, marker-free. NOTE: git itself leaves theirs in
-    // surviving Docmost body on `main` instead of dropping it. No markers.
+    // the working tree for a modify/delete (stage 3), so this asserts the clean-merge
+    // happy path rather than the `?? theirs` fallback in isolation — that branch is
+    // guarded by the fake-fs unit test in apply-pull-actions.test.ts.
     const onMain = await readFile(join(dir, file), 'utf8');
     expect(onMain).toContain('Modified on DOCMOST');
     expect(onMain).not.toContain('<<<<<<<');