test(diff): pin gridSpan/vMerge property-only table change scope (#230)

[JSv4]

Closes #230.

What #230 asked

The IR did not model property-only table/cell changes (w:tcPr / w:tblPr / gridSpan / vMerge): a reviewer who changed only cell shading/borders/width, table properties, or cell spanning produced an IR whose content/format fingerprints were identical to the base, so both 2-way DocxDiff.Compare and consolidate treated the table as EqualBlock — the change was silently invisible (no revision, no markup, no conflict).

Acceptance criteria: (1) a tcPr-only cell change is detected as a format change in 2-way Compare and composes/conflicts in consolidate; (2) document the chosen scope for gridSpan/vMerge (detect vs. compose); (3) base 2-way parity floor holds, full suite green.

What I found (proved with a fixture)

I first wrote a throwaway probe that ran DocxDiff.Compare / Consolidate over programmatic tables and inspected the IR hashes + emitted markup. Ground truth:

• The core soundness gap is already resolved by the block-format-change family (PR feat(diff): close the N-way Consolidate gap — note merge, column composition, native split/merge/row-moves, cell-shell visibility #250/feat(diff): block-format family follow-ups A — tblPrExChange, mid-doc sectPrChange, public opt-out, note/hdr-ftr pPrChange #253) and consolidate cell-shell composition. IrCell.ShellDigest (the whole w:tcPr) is folded into the cell ContentHash, so a shell edit makes the table Modified.
• 2-way Compare now tracks every property-only case — shading, width, vMerge-only, and gridSpan-only — as native w:tcPrChange with a TableCell FormatChanged revision, round-tripping accept ≡ right / reject ≡ left at the tcPr-byte level.
• Consolidate composes a vMerge/gridSpan cell-shell edit exactly like a width/shading edit (lands on accept, reject ≡ base, conflict on competing shells).
• Even a column add/remove (cell count changes) is detected (content hash differs) — never silently invisible.

The genuinely-unmet parts were criterion (2) — the gridSpan/vMerge scope was never explicitly documented — and the absence of direct regression fixtures for that corner. So this PR closes the proof + documentation gap rather than touching the (already-correct) engine.

Changes

• BlockFormatChangeTests.{GridSpanOnly,VMergeOnly}_cell_change_is_tracked_with_native_tcPrChange — 2-way pins: a gridSpan- / vMerge-only change (cell count stable, text unchanged) → native w:tcPrChange, TableCell FormatChanged revision, clean round-trip, schema-valid, no spurious ins/del.
• IrCompositeTableTests.VMerge_only_cell_edit_composes (3 conflict policies) — consolidate pin: the reviewer's vMerge lands on accept, reject ≡ base, no conflict.
• docs/architecture/ir_diff_engine.md — the explicit gridSpan/vMerge scope decision: detect (2-way) / compose (consolidate) / column-structure fallback / ["shell"] changed-name granularity rationale.
• CHANGELOG.md — [Unreleased] entry.

No production code changed — the behavior already held; this makes it auditable and regression-proof.

Verification

• Full test suite: 2607 passed, 3 skipped, 0 real failures (the one flaky failure was IrAlignerAdversarialTests.Scale_guard_..., a wall-clock micro-benchmark that failed only under full-suite CPU contention and passes 3/3 in isolation — unrelated to these test/doc-only changes).
• Both parity scoreboards (IrParityScoreboardTests, ConsolidateParityScoreboardTests) green — the 2-way parity floor holds.

---

Generated by Claude Code