fix: keep both panes visible in the studio split view

[bero]

Independent of #7 and #8. This branch is cut from main and touches different code, so it can merge in any order.

The bug

Split view collapses into what looks exactly like editor only. The preview disappears, and switching modes never brings it back. Making the window wider is the only recovery.

The editor width is remembered as an absolute pixel value and reapplied without checking the space available. Once it exceeds the room left after the contents pane and the splitter, the editor takes the whole area and the preview is given zero width. Because every later return to split reapplies the same value, the state is sticky. The resize handler did not touch the split at all, so narrowing the window triggered it with no mode switch involved.

Measured with the x positions of the pane dividers. Two dividers means the preview is present, one means it is gone.

Step	Window	Dividers
Baseline split	1200	248, 732
Dragged splitter right	1200	248, 1090
Editor then split	1200	248, 1090
Shrunk window, no mode change	900	248
Editor then split	900	248
Preview then split	900	248
Widened window again	1200	248, 1090

A second report against the first version of this branch found the same symptom through the contents divider: dragging it right left the preview at 36 pixels. That is fixed here too, in the second commit.

The fix

A new framework free unit, Examples/Shared/Markdown4DStudio.SplitLayout.pas, holds the rules so they are testable without a form and shared by both studios:

• ClampEditorWidth keeps the editor between the minimum and whatever leaves the preview its minimum. Below two minimums the space is shared evenly rather than handed to one pane.
• EffectiveMinPaneWidth gives the minimum a splitter can actually enforce right now. A splitter asked to honour a minimum the window cannot give lets a drag collapse the other pane, which is a real failure on a narrow window.
• ClampSidePanelWidth bounds the contents pane, so it cannot grow, or stay wide, at the cost of the two halves.

The result is an order of priority. The contents pane gives way first so the editor and preview keep their 300 pixels. It never gives way past its own minimum of 120, and below that the two halves share what is left between them. A contents pane the user already dragged narrow is never widened by the clamp.

Both forms apply this from every route that changes the split: entering split view, resizing the window, toggling the contents pane, and finishing a drag on either divider. Entering split view asks for the remembered width; the other routes pass the width the editor already has, so a deliberate drag is kept and only trimmed when it no longer fits.

The FMX splitter has no moved event, so its drags are caught on mouse up.

Testing

Nine DUnitX tests cover the helper, including regression cases built from the measurements above. Each was written first and confirmed failing before the production code existed.

• Full suite: 1097 tests, all passing.
• Markdown4DStudioVCL, Markdown4DStudioFMX and Markdown4D.Tests all build clean on Win32 Debug with Delphi 12 Athens.
• Drove the VCL studio through every route. Dragging either divider to an extreme, resizing down to 900 and toggling the contents pane all leave both panes at or above 300. At 700 wide the contents pane has reached its own minimum, so the two halves settle at 282 and 284, which is the documented even split.

The FMX side is covered by the shared tests and identical wiring, but was not driven interactively: its Skia canvas does not capture through PrintWindow, which made scripted visual checks unreliable on my machine.

Known limitation

Widths are pixel values, not proportions. Shrinking the window trims the editor and the contents pane, and widening it again does not restore their earlier widths. A proportional split would fix that and is a larger behavioural change, so it is deliberately out of scope here.