Exploded view remembers where you drag its windows

Ported from BT411's BT_GLASS_LAYOUT (29c502d).

The exploded view's panes are draggable desktop windows, but the
arrangement is recomputed on every launch, so dragging one somewhere
useful never survived the menu-race-menu loop.

RP412MFDLAYOUT persists it to mfd_layout.cfg beside bindings.txt:

  off / 0 / unset   computed arrangement only, no file (default)
  load / restore    restore saved positions at startup, never write
  save / adjust     restore, then rewrite on each finished drag
                    (WM_EXITSIZEMOVE) and on teardown

One "<title>=x,y,w,h" line per pane. Position is restored and the size
read and discarded: a pane's size follows its content and its button
banks, so letting an old size back in would misshape it after any
geometry change - and this port has changed that geometry twice already.

Load runs after the computed arrangement rather than instead of it, so a
pane the file does not mention simply keeps its computed spot. Only the
exploded view registers: the composited cockpit's panes are chrome-less
children with nothing to drag, so they have no position worth keeping.

RP412 needs no equivalent of BT411's "restored" flag. Its re-snap is
LayoutCockpit on WM_SIZE, which only runs in cockpit mode, so nothing
comes back later to overwrite a hand-placed window.

Verified by round trip: dragged Map to 777,333 in save mode, the file
took all six panes, and a fresh launch in load mode put it physically
back at 777,333. The harness also resized the window while moving it,
which incidentally proved the saved size really is ignored - the pane
came back correctly sized from a cfg that recorded 136x39.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

MUNGA_L4/L4VB16.cpp

@@ -4457,6 +4457,13 @@ SVGA16::SVGA16(
 		splitView[SplitMFDLowerRight]->SetPosition(
 			work.left + right_x, work.top + bottom_y);
 		splitView[SplitMap]->SetPosition(work.left + map_x, work.top + map_y);
+
+		//
+		// ...and then let RP412MFDLAYOUT put back anywhere they were
+		// dragged to last time. Panes the file does not mention keep the
+		// arrangement just computed above.
+		//
+		MFDSplitView_LoadLayout();
 	}
 	else if (splitViews)
 	{
@@ -4863,6 +4870,14 @@ SVGA16::~SVGA16()
 	//---------------------------------------------------------
 	//SVGASetSplitterClock(False);
 
+	//
+	// Backstop for the sticky exploded-view placement: every finished drag
+	// has already been written, but a pane moved and then closed straight
+	// away would otherwise be missed. Must run before the panes go - it
+	// reads their live window rects.
+	//
+	MFDSplitView_SaveLayout();
+
 	for (int view = 0; view < SplitViewCount; ++view)
 	{
 		delete splitView[view];