Add draggable table column resizing

[aseelye]

Adds draggable column resizing for Markdown tables in the live preview, with widths persisted outside the Markdown file in Application Support. Includes renderer and persistence tests.

[schuyler]

Thanks for this — a lot of careful work, and the non-persistence parts are well done: the token-gated x-macdown-table-layout:// bridge cleanly mirrors the existing checkbox pattern, the drag UX is solid, and the Save-As tests are thorough. I'd like to land table resizing.

My main concern with this PR is the persistence model, not the feature. The path-keyed table-layouts.json under Application Support adds a third state-persistence pattern to the app — today we only have NSUserDefaults and writing back into the Markdown source (the checkbox toggle, #269). A path-keyed sidecar is a format we'd have to support forever, and it's fragile: widths orphan on rename/move, the header-hash resets them when a heading is edited, the global file races across open documents, and entries never get pruned.

How would you feel about persisting column widths in the document itself, using the table's delimiter row? A pipe table's delimiter dashes are ignored by the renderer (only colons matter), so we could co-opt dash count as a proportional width:

| Name | Description                   | Qty |
| ---- | ----------------------------- | --- |

→ apply <col style="width: N%">, and on drag-release rewrite the delimiter line in the source via the same path the checkbox toggle already uses. That keeps everything in one pattern we already have: no sidecar, no path-keying, no GC — the widths are the file, so they travel with it and degrade gracefully (other renderers just see a normal table). The tradeoff is widths become proportional rather than pixel-exact, which I think is the right call for a reflowable document anyway.

I confirmed our renderer cooperates: against our pinned hoedown 3.0.7, dash count above the minimum has zero effect on output (--- vs a 40-dash run are byte-identical). The only constraint is a floor of ≥3 chars per cell, so the recompute just clamps each cell to ≥3 dashes.

You'd keep essentially all the front end — handles, CSS, bridge, colgroup logic; only the persistence half changes. Happy to take that piece on myself if you'd rather not redo it.

(Separately: the baseline #432 regression is handled in #440, so this PR can focus purely on resizing.)

---

Generated by Claude Code

[aseelye]

Putting the formatting in the document would make it incompatible with prior versions of macdown and just about every other markdown editor out there. A local store of this data in a user folder could suffice, or if they didn't want that, to just resize as needed each time it's opened. The former would be preferred though.

[schuyler]

Putting the formatting in the document would make it incompatible with prior versions of macdown and just about every other markdown editor out there. A local store of this data in a user folder could suffice, or if they didn't want that, to just resize as needed each time it's opened. The former would be preferred though.

I like the idea behind this feature and I agree that it should be persistent. I didn't realize just what a pain it was to have the fixed column widths.

What do you mean when you say "incompatible with prior versions of macdown and just about every other markdown editor out there"? Aside from doing a quick spike in Hoedown to make sure that the idea would work, I only did a cursory search but I am unaware of any Markdown parsers that care how many dashes are present in that row. If I'm missing something, please let me know!

Even beyond my vague concerns about long term maintenance burden, I'd love it if we could find a solution that doesn't break if a user copies the file to a different computer, or potentially, a different folder on the same computer.

[jclark-dot-org]

As an observer who came here to report a table rendering issue (see image), +1 for the idea, and +1 for storing in the markdown text. I'd much rather see the unrendered text with sensible column sizes anyway.

This is what my raw MD looks like (generated by Claude); it's fine if you only plan to render, but Markdown was designed to be readable without rendering, and minimal-width-columns are anything but.

| Object | Status | Gating for me |
|---|---|---|

[aseelye]

Yeah, it's a good idea. I'm not sure if I should build in the things like alignment/justification as the Github Flavored Markdown spec allows. I'd personally say 'yes', with an option in the Settings dialog to allow/disallow it, but that might turn into biting off a lot more than would be appropriate.