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/L4MFDVIEW.h

@@ -77,6 +77,14 @@ public:
 	void
 		Hide();
 
+	// caption and HWND, for the sticky-placement file
+	const char *
+		Title() const
+			{ return paneTitle; }
+	void *
+		Window()
+			{ return window; }
+
 	~MFDSplitView();
 
 	Logical
@@ -147,4 +155,42 @@ protected:
 	int
 		buttonAnchorA,
 		buttonAnchorB;
+
+	// the window caption, and the key this pane is saved under
+	const char
+		*paneTitle;
+	// True for a pane of its own on the desktop (the exploded view); the
+	// composited cockpit's panes are chrome-less children and cannot be
+	// dragged, so there is nothing to remember for them.
+	Logical
+		ownWindow;
 };
+
+//########################################################################
+// Sticky window placement for the exploded view (L4MFDSPLIT=2).
+//
+// Those 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 and
+//                     on teardown - the round trip
+//
+// One "<title>=x,y,w,h" line per pane. Position is restored and size
+// ignored: a pane's size follows its content and its button banks, so an
+// old w,h from a different build must not distort it.
+//
+// Ported from BT411's BT_GLASS_LAYOUT.
+//########################################################################
+
+// Apply saved positions over the computed ones. Call after the panes are
+// built and placed.
+void
+	MFDSplitView_LoadLayout();
+
+// Write every open pane's position. No-op unless the mode is save.
+void
+	MFDSplitView_SaveLayout();