Never let a nested srdwm rewrite the real session's desktop config

My own testing changed the owner's GTK button style. Nested instances were
started with a scratch srdwm config, which naturally does not set
button_style, so the built-in default applied and publish_gtk_stylesheet
wrote traffic-light CSS into the real ~/.config/gtk-3.0/srdwm-buttons.css --
changing how every GTK app looked in the actual session, from a throwaway
compositor that was testing something unrelated. Their own config and the
running compositor both said "traditional" the whole time; only the
generated file disagreed, which is why it looked like the feature had
regressed.

Both publishers now return early when running nested, using the same test
srdwm_wayland::connect uses to choose the winit backend over udev/DRM: a
host WAYLAND_DISPLAY or DISPLAY means there is already a session and this
process is a window inside it. A nested instance is a test window, not the
shell, and has no business rewriting settings the real session is using.

Verified: with the guard in place a nested run leaves the file byte-identical
(md5 before and after), where before it would have rewritten it from the
default.

This is the same class of mistake as sending synthetic clicks to the wrong
compositor earlier - a test instance reaching outside its own sandbox --
and it wants a structural guard rather than remembering to set HOME.

533 tests pass, clippy clean.

0 files changed, 0 insertions, 0 deletions