Fix the nested guard: it answered wrong for a real session, and missed a case

The guard added earlier tonight asked "is WAYLAND_DISPLAY or DISPLAY set".
Both Wayland backends call set_var("WAYLAND_DISPLAY", ...) on themselves the
moment they bind their own socket, so after startup that question answers
"yes" for a real udev session too. Every publish on the config-reload path
runs after that point, which means a live session that reloaded its config
would have stopped publishing its own GTK settings - the exact opposite of
what the guard is for. It also treated srdwm-x as nested, because an X11
session naturally has DISPLAY set, even though srdwm is that display's
window manager and not a client of anything.

Nestedness is now read once, at startup, before any backend is up, and
only the Wayland backend can be nested. A test pins the second half.

The same reasoning applies to window_memory::save_all, which had no guard
at all: a nested instance shares HOME with the session it runs inside, so
dragging a test window would overwrite where that application opens in the
real session - a 1280x800 test window's position applied to a 3840x1080
desktop. Loading stays unconditional and deliberate: honouring what a real
session remembered is right, writing back over it is not. That side reads
srdwm_wayland::running_nested, recorded by connect at the moment it picks
the winit backend, since the environment can no longer be asked afterward.

Verified: a nested run with a scratch config left both the stylesheet and
window-memory.json untouched (md5 before and after, and no test window's
app-id in the store).

1 files changed, 12 insertions, 0 deletions

diff --git a/crates/wayland/src/window_memory.rs b/crates/wayland/src/window_memory.rs
index b2d3711..4376274 100644
--- a/crates/wayland/src/window_memory.rs
+++ b/crates/wayland/src/window_memory.rs
@@ -113,7 +113,19 @@ pub(crate) fn load() -> HashMap<String, PersistedGeometry> {
 /// story (the same reasoning `monitor_layout::save_output` and `desktop_
 /// icons_state`'s own saver already settled on for the identical shape of
 /// problem).
+///
+/// A nested srdwm never writes it. It shares `HOME` with the session it is
+/// running inside, so a window dragged around in a test compositor would
+/// otherwise overwrite where that same application opens in the user's real
+/// session - a 1280x800 test window's position applied to a 3840x1080
+/// desktop. Loading stays unconditional and deliberate (see `connect`'s own
+/// call site): honouring what a real session remembered is right, writing
+/// back over it is not. Same reasoning as `publish_gtk_stylesheet`'s own
+/// nested guard.
 pub(crate) fn save_all<'a>(entries: impl Iterator<Item = (&'a str, (i32, i32, u32, u32))>) {
+    if crate::running_nested() {
+        return;
+    }
     let apps: HashMap<String, PersistedGeometry> =
         entries.map(|(app_id, (x, y, width, height))| (app_id.to_string(), PersistedGeometry { x, y, width, height })).collect();
     let memory = PersistedWindowMemory { apps };