Saving pads a ragged table row into new cells

[Azganoth]

Summary

A table whose rows hold differing cell counts is read as written and saved padded to the widest row. The document gains cells it did not have, and a body row wider than the header promotes its extra cells into real columns, changing what another parser reads from the file.

Steps to reproduce

1. Open a document containing:

   | A | B |
   | --- | --- |
   | one |
   | two | three | ignored |

2. Save it without editing.

3. Reopen the saved file.

Expected behavior

The document after reopening matches the document before saving. Whether the editor normalizes ragged rows on open is a separate question; what it must not do is change the document on a save the author did not ask for.

Actual behavior

Measured against 9626471d by driving the editor mount used by the plugin tests. The parse keeps the ragged shape — a two-cell header, a one-cell row, and a three-cell row. The save writes three columns throughout:

| A   | B     |         |
| --- | ----- | ------- |
| one |       |         |
| two | three | ignored |

The header gains a third table_header, and the short row gains two table_cells.

The shorter-row case does the same on its own: | A | B | with a single | one | body row saves as a two-cell row.

corpus/gfm/tables.md carries both under Ragged body rows are padded or truncated, and they are why that file's document differs across one save. That heading says rows are padded or truncated on read; measurement shows the parse preserves them and the save pads.

Related context

• Related issues or pull requests: found while probing How a Markdown escape should be represented in the editor #245; corpus/gfm/tables.md previously failed Determine whether the Markdown corpus can drive automated round-trip tests #135's convergence check for an unrelated reason, the list-item nesting bug fixed as A list item's non-paragraph first child loses its nesting on save #247, so this is a second and independent defect in the same file
• Documentation, decisions, or prior investigation: the Outcome section of How a Markdown escape should be represented in the editor #245; corpus/gfm/tables.md

Done when

• Both fixtures above preserve their document across a save.
• Regression coverage asserts the document rather than only serialized stability.
• corpus/gfm/tables.md preserves its document across a save, and its Ragged body rows heading matches what actually happens.

Notes, logs, screenshots

Like the HTML line-break defect filed alongside it, this converges cleanly and corpusRoundTrip.test.tsx is green on it. The damage lands on the first save and every pass after that is stable, so convergence cannot see it.

Diagnosis

Not established. The divergence is between what the parse admits and what the serializer emits; which side should move was not decided.

Out of scope

• Column alignment and padding whitespace, which are cosmetic and already stable.
• The HTML line-break defect found alongside it, which is filed separately.