feature: optional preview-buffer rendering for wrapped, navigable tables

Is your feature request related to a problem? Please describe.

Long table cells are difficult to read in narrow windows. Wrapping the underlying Markdown line does not
preserve the table's column layout, while generated virtual lines require additional handling for cursor
movement, selection, and copying.

Related requests include #536 and
#616.

Describe the solution you'd like

I have implemented a prototype that renders tables as real text rows in a separate preview buffer, while
keeping the original Markdown buffer responsible for editing, undo history, and saving.

Short columns retain their natural width where space permits. The remaining width is distributed among
longer columns. Cell contents wrap at word boundaries, with oversized words or identifiers split when
necessary. Each table row expands to accommodate its tallest cell.

Ordinary Markdown around the table continues to use render-markdown.nvim.

Demonstration:

The GIF shows long descriptions wrapping beside aligned short cells, an oversized identifier splitting
across lines, cursor movement through wrapped content, visual selection and copying, and a quick status edit
followed by undo/redo.

Benefits

• Readable tables within the window: long cells expand vertically while preserving column alignment.

• Native navigation and copying: continuation rows are actual buffer lines, so movement, search, selection,
  and yanking work on their text.

• Source-backed editing: supported edit commands return to the corresponding source cell; preview resumes
  afterward.

• Incremental updates: unchanged table layouts can be cached, with only changed preview ranges updated.

Costs and limitations

The additional preview buffer requires memory, layout work, and source-position mappings. Those mappings
must account for wrapped lines, UTF-8, links, and inline formatting.

Editing also becomes more complex: the preview remains read-only, supported quick edits run in the source
buffer, and arbitrary visual edits require switching to source mode. Saving, modified state, link
navigation, and cursor restoration must preserve the source buffer's behavior.

The prototype demonstrates feasibility; it does not establish a performance improvement over the current
renderer.

Possible upstream support

The existing preview already separates source and presentation. Supporting this approach would additionally
require:

• Table projection into real display rows, with highlights and source mappings.
• A way to exclude generated table rows from ordinary Markdown parsing.
• Refresh handling for source edits and window resizing, with source-position preservation.

This could be an optional preview mode or a supported interface for a companion plugin.

The same projection interface could later support Mermaid diagrams through an external renderer, though
precise diagram-to-source mapping would require additional metadata.

Describe alternatives you've considered

Using a separate table-viewing plugin is another option. It could open large tables in a dedicated buffer with wrapping, navigation, and copying support.

Additional information

No response

Start by reading the existing preview renderer and its source/presentation separation, then trace table rendering and refresh behavior. Compare the prototype’s required projection, wrapping, source mappings, resizing, and edit/cursor behavior with the current interfaces. Done means an agreed optional preview mode or supported companion-plugin interface that preserves source editing, saving, navigation, and ordinary Markdown rendering.