Fix window memory never saving on close, and split-screen icon/primary bugs

Screenshotted the just-split display on request rather than guessing --
it showed why windows never seem to remember placement/size, plus two
real split-screen bugs.

Window memory (WindowManager::remembered_geometry) was correctly wired
on the read side, but the only writes came from end_drag/end_resize in
dragresize.rs - a real drag or resize. A window the user opens, looks
at, and closes without ever touching its edges had nothing recorded, so
reopening it always fell back to a fresh cascade placement, for what is
probably most ordinary window lifecycles. remove_window now also
snapshots geometry (same app_id-non-empty gate the drag/resize sites
use), persisted at both of its wayland-side call sites the same way the
drag/resize-release site already does.

desktop_icon_origins mirrored the full icon set onto every Monitor entry
when general.desktop_icons_all_monitors is on - which, after a
srd.monitor.split, is one entry per split part of the same physical
screen, not one per real monitor. Extracted into a separately-tested
icon_origins_for that collapses split parts of the same connector back
to one origin, keeping a genuinely separate monitor's own origin intact.

Found while fixing that: every split part also reported primary: true
(computed from the connector's name, which doesn't vary per part) --
fixed by gating on part == 0 too.

1 files changed, 12 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 67ff09a..fbe5ec9 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -1,5 +1,17 @@
 # TODO / planned features - master checklist
 
+## Three real bugs found from one screenshot: window memory never saved on close, split screens duplicated desktop icons, split parts all claimed primary (2026-08-27)
+
+Asked directly why windows always spawn top-left and don't remember placement/size, and to screenshot the just-split display since it "doesn't look like 2 more monitors, just showing double desktop icons." Took a real `grim` screenshot rather than guessing from code, and it showed both reported symptoms at once plus revealed why the first one happens at all.
+
+**Window memory only ever saved on a manual drag/resize release.** `WindowManager::remembered_geometry` (per-`app_id` last floating position+size, read at window-map time) was real and correctly wired on the *read* side, but the only two places that ever wrote to it were `end_drag`/`end_resize` in `dragresize.rs` - a real user action, mouse button released after actually dragging or resizing. An app the user opens, looks at, and closes without ever touching its edges or titlebar had nothing recorded at all, so reopening it always fell back to a fresh cascade placement - indistinguishable from the feature not existing, for what is probably the *majority* of ordinary window lifecycles. Fixed by also snapshotting geometry into `remembered_geometry` from `WindowManager::remove_window` itself (gated the same `app_id`-non-empty way the drag/resize sites already are), and persisting it to disk at both of `remove_window`'s two wayland-side call sites (`state/lifecycle.rs`'s native unmap path, `xwayland.rs`'s X11 equivalent) the same way `input/pointer.rs`'s drag/resize-release site already does.
+
+**A split screen mirrored the full desktop-icon set onto every split part.** `desktop_icon_origins`'s "mirror icons onto every monitor" mode (`general.desktop_icons_all_monitors`, the default) iterated every `Monitor` entry `srd monitors` reports - which, after a `srd.monitor.split`, includes one entry *per split part*, not one per real physical screen (see `Monitor::split`'s own doc comment: "not a second wl_output, not a second physical connector"). Two icon columns side by side on what is still one continuous physical desktop read as a visual bug, not "2 more monitors" - which is exactly the screenshot. Fixed in a new, separately-testable `icon_origins_for` (pulled out of `desktop_icon_origins` the same way `udev/outputs.rs::next_logical_x` was pulled out of `relayout_outputs`): a split part's name is always `"{connector}-{part}"`, so recovering the connector and keeping only the lowest-id part per connector collapses every split group back to the one real screen it is, while a genuinely separate monitor (real or fake) still gets its own origin.
+
+**Every split part reported `primary: true`, not just one.** Found while fixing the above: `platform.rs`'s per-part loop computed `m.primary` from the *connector's* name, which doesn't change across `0..parts`, so a primary connector's split produced two-or-more `Monitor` entries all claiming primary - silently broke the "exactly one primary monitor" assumption several callers reasonably make (including the icon-origin fix's own single-monitor branch, which just took whichever `.find(|m| m.primary)` matched first). Fixed by gating on `part == 0` too.
+
+Full workspace build/test/clippy clean (224 core / 146 wayland tests, both up from before). Not yet live-verified against a real restart - needs one, same as everything else this session.
+
 The single consolidated list of pending work. Before this file, "what's
 left" was scattered across four places that each grew their own list
 independently (`MISSING.md`, `PANEL_SUPPORT_TODO.md`,