drm: close the round-17 review findings

- the scanout dma-buf fd is duplicated with F_DUPFD_CLOEXEC. `dup(2)`
  never copies close-on-exec, so this fd was inherited by every child
  the ROOT service forks (it forks synchronously for the loginctl
  active-uid lookup) - and what this fd names is the live screen
  contents. this is the SAME defect already closed on the `_drm`
  socket fd in ipc/drm.rs; fixing that one and not grepping for the
  siblings is how this survived. there is exactly one dup in the drm
  path now and it is this one, verified by grep. measured that
  F_DUPFD_CLOEXEC sets FD_CLOEXEC and preserves the O_RDONLY access
  mode the read-only export depends on; SCM_RIGHTS delivery is
  unaffected since the receiver gets its own descriptor.
- Desktop::refresh resolves HOME on the login-Wayland path too, since
  the drm build now starts a --server as the greeter uid there and a
  child with no HOME has nowhere to put its config. the compositor
  variables stay blank deliberately: the drm path talks to the root
  service and a render node, never to the compositor or the portal,
  which is why it works at a login screen at all. reasoned, not
  measured: a current GDM runs its greeter as `gdm-greeter`, which
  `is_gdm_user` does not match, so that path is not reachable on our
  hardware - measured there, the greeter server gets a fully populated
  environment through the branch below.
- the glibc-floor step globs into an array and asserts the count, like
  its sibling assert step. that sibling was fixed two rounds ago and
  this one was left behind.

src/platform/linux.rs

@@ -2062,6 +2062,23 @@ mod desktop {
                 self.display = "".to_owned();
                 self.xauth = "".to_owned();
                 self.is_rustdesk_subprocess = false;
+                // Resolve HOME even on this path. Upstream returned without it because nothing then
+                // consumed a login-Wayland Desktop, but the drm build starts a `--server` as the
+                // greeter uid here, and a child with no HOME has nowhere to put its config. The
+                // compositor variables (WAYLAND_DISPLAY, DBUS, DISPLAY, XAUTHORITY) are left blank
+                // on purpose and are NOT an oversight: the drm capture path talks to the root
+                // service over `_drm` and to a render node, never to the compositor or the portal,
+                // which is the entire reason it works at a login screen. `try_start_server_` skips
+                // empty entries, so the greeter child simply does not get them.
+                //
+                // NOT REPRODUCIBLE ON OUR HARDWARE, so it is a reasoned fix, not a measured one:
+                // `is_login_wayland` needs `is_gdm_user(username)`, and a current GDM runs its
+                // greeter as `gdm-greeter`, which that helper does not match -- measured on the
+                // test host, where the greeter server therefore takes the branch below and gets a
+                // fully populated environment. This is for the display managers whose greeter user
+                // does match.
+                #[cfg(feature = "drm")]
+                self.get_home();
                 return;
             }