Column diff emits delete-all + insert-all, can leave table with 0 columns mid-batch

[sripathikrishnan]

Context

Discovered while live-testing the tableStartLocation index-shift fix (commit f6f198e).

Symptom

When the reconciler diffs a table whose columns changed, diffmerge/table_diff.py sometimes emits a strategy of "delete every existing column, then insert every new column". In a 3-column table this means deleteTableColumn is issued 3 times in sequence, taking the table through a 2-col → 1-col → 0-col intermediate state.

Google Docs API rejects the third delete:

Cannot remove the last column from a table.

The whole batch aborts, no changes land.

Reproduction

Hit during one combined test in the f6f198e live verification (combined edits + column append path). The requests themselves had correctly shifted indices — the bug is purely in the column diff strategy choosing an illegal intermediate state.

Root cause

extradoc/src/extradoc/diffmerge/table_diff.py column diff path — when it can't cleanly map existing columns to desired columns via LCS, it falls back to delete-all + insert-all. This is a legal transformation for the data but an illegal one for the API.

Fix direction

Column diff must guarantee the table always has ≥1 column at every intermediate step. Options:

1. Insert new columns first, then delete old ones (keeps column count ≥ desired during transition).
2. Interleave inserts and deletes so count never drops below 1.
3. Fall back to keeping at least one "bridge" column to preserve via content update rather than delete+reinsert.

Same concern applies to rows: can't delete the last row of a table either.

Tests to add

• Diff where all columns replaced: verify batch never takes the table below 1 column.
• Diff where all rows replaced: verify batch never takes the table below 1 row.
• Small table with full column replacement: assert column count at every intermediate step ≥ 1.

[sripathikrishnan]

Additional repro case (from #60 live verification)

Encountered again during multi-append live testing (commit 2563465): pushing a 2x2 → 3x3 edit (add 1 row AND 1 column in one push) triggers the same "delete-all + insert-all" column strategy.

Scenario: base has 2x2 table A1/B1 / A2/B2. Desired has 3x3 table with existing cells preserved and new row + new column added.

Diff plan emitted:

insertTableRow + 2×deleteTableColumn + 3×insertTableColumn

Base table has only 2 columns. The 2 deletes take the table through 1-col → 0-col → (rejected). API returns:

Invalid requests[6].insertTableColumn: Invalid table start location

The whole batch aborts. Reproduces with or without #60's fix on main.

Mechanism: when both a new row AND a new column are added simultaneously, the column-diff path appears to fall through to delete-all-existing + insert-all-new rather than finding a stable column LCS that would preserve the 2 existing columns and add 1 new one. A pure "add 1 column" diff (2x2 → 2x3) uses the single-column-insert path correctly — only the mixed row+column case triggers delete-all.

Additional test case to add:

• 2x2 → 3x3 diff (1 new row + 1 new column): assert the plan does not delete all existing columns.