Module layout 

Lay out markdown pipe tables so their columns line up (HP.1).

Help pages are markdown, and nothing between the .md file and the help buffer used to touch tables — so a reader saw the raw source: |---|---| rows rendered literally, and cells whose widths had nothing to do with each other.

Why display width and not char count. The docs that were hand-padded were padded by counting characters, which is a different number from the columns a terminal advances. ✓, ─, ↑, ▸ and every CJK glyph break that assumption, so a table looked aligned in the source file and ragged on screen — the specific complaint this module answers. [unicode_width] measures what the terminal will actually do.

Why here and not in a renderer. Two reasons, and the second is the load-bearing one:

1. A renderer-side pass is two implementations (TUI and GPUI) of one piece of text layout.
2. The buffer’s text would then differ from what is on screen, so / search, w motions, visual selection and yank would all operate on columns the reader cannot see. Formatting the text keeps “what you see” and “what the buffer holds” the same string.

Ordering constraint. This runs BEFORE lattice_help::extract_links_and_clean, never after. Link ranges are recorded against the cleaned text, so inserting padding afterwards would slide every link on a padded row and <CR> would follow the wrong one. Running first means extraction sees the final bytes and the ranges come out right with no offset bookkeeping — which is why visible_width strips link markup for measurement only: the column has to be as wide as the label the reader sees, not as wide as [label](help:some-page).

Enums

Align

Column alignment, from the separator row’s : markers.

Functions

format_tables

Reformat every pipe table in lines, leaving everything else byte- identical.