fix: fit every table's columns in one layout

[Azganoth]

Summary

Fitting table columns took each table's previous fit off, read its first row's cell widths, and wrote the new colgroup before moving to the next table, so every table's read followed the previous table's writes and forced its own layout. The fit now takes every table that needs fitting, removes all their fits, reads all their widths, and only then writes the new column widths. Widths are still read with the previous fit taken off, and which tables are refitted is unchanged: the table holding the caret keeps its widths, a resize refits the rest, and a table the caret has left is refitted.

Related Issue

Closes #686

Verification

• pnpm exec vitest run src/features/editor/plugins/tableColumns.test.ts: the plugin had no tests. The new ones emulate layout so a fitted table reports its fitted widths, and cover the first fit, the held table, a resize, and a table the caret has left. They assert the widths and that no table being refitted carries a fit when any width is read. Against the previous plugin, the width assertions pass and only the read-order assertions fail.
• pnpm check:frontend passed.

Manually verified in isolated Windows 11 release builds with source maps, driven over the WebView2 DevTools protocol with #680's method, opening #680's 500 KB table fixture (45 tables of 120 rows and 6 columns) from the welcome screen. main and this branch alternated, five opens each. Open time runs from the click to the end of the last long frame. Three of the machine's twelve logical processors were busy with unrelated work throughout, and both builds opened slower than #680's 3.1–3.7 s on main at 33016d8, so compare the two columns rather than the absolute times:

	main (9aa80f9)	This branch
Open, median (range)	5.04 s (4.02–7.65)	4.16 s (4.08–4.34)
Longest frame, median	4.12 s	3.98 s
Forced style and layout, median	1.73 s	1.56 s
Layout events in a traced open	102	14
Layout time in a traced open	733 ms	603 ms

The open median overstates the gain because of main's slow outliers; the longest frame and forced layout put it at about 0.15 s.

Not verified: keystroke timings, which the change does not touch, and the 1 MB fixture, which got only three usable runs under heavier load.

Notes

The 500 KB table document still misses the 3 s open budget. Most of the time #680 attributed to the fit's width reads is a restyle of about 65,000 elements, left pending when the editor gives its headings ids, that the fit's first read happens to pay. #695 covers it.