drm: clear the stale _drm entry by fd, and fix three comments that argue backwards

new_drm_listener cleared the stale socket with std::fs::remove_file, which is
unlink(2). Against a directory-typed squatter that returns EISDIR and leaves the
entry in place, and endpoint.incoming() then fails EADDRINUSE, so DRM capture
falls back to the portal for the rest of the boot over an entry we could have
removed. The _service listener has never had that hole: it removes entries
through a no-follow fd on the parent directory, fstatting the entry first and
choosing AT_REMOVEDIR when it needs to. That helper now takes a path instead of
a postfix, so the _drm listener - which deliberately stays outside hbb_common's
postfix machinery - can use the same one on the directory it just hardened. The
precondition is narrow (an unprivileged process has to win the creation race
before the root service first hardens the dir on a fresh boot), which is why the
failure is a warn and not a bail.

Three comments stated their reason backwards or more strongly than the code
supports. None of them changes behaviour; all three would send the next reader
to verify the wrong thing.

The wake's 20 s rate limit was justified as being short enough to be useless as
a way to keep a screen lit. That is inverted: a shorter gap would make relighting
easier, not harder, and 20 s is below every idle period we have measured (30.3 s
at a greeter, 70.3 s in a session). What actually bounds it is that the wake is
one-shot, which the next sentence of the same doc already says. Fixed at both
sites, the constant and the security doc.

The doc block above drm_enumerate_settled reads as one paragraph but spans a cfg
split, so its shared contract and the wake-less specialisation looked like one
statement about the arm below it. Marked explicitly.

And get_primary_index claimed its answer agrees with the advertised geometry by
construction, which is true only where augment_with_wayland_geometry runs the
same assignment - it declines below two connectors or two outputs, and in that
band the two functions run different code. The answer is still never worse than
the documented fallback there, and now the comment says which.

docs/DRM_CAPTURE_SECURITY.md

@@ -180,8 +180,10 @@ presents) but reuses RustDesk's own hardened IPC.
     that is never coming;
   - it is rate limited to **one wake per 20 s process-wide** with exactly one
     concurrent winner (compare-exchange claim), so a reconnect storm cannot
-    become an input-injection storm, and it is useless as a way to keep a
-    screen lit;
+    become an input-injection storm. The limit is not what stops the wake being
+    used to hold a screen on -- 20 s is shorter than every idle period measured
+    below, so a shorter gap would make relighting easier, not harder. What
+    bounds that is the next point;
   - the wake is **one-shot: it resets the compositor's idle timer, it does not
     hold the display on**. If nothing else keeps the session awake, the connector
     idles off again one full idle period later -- measured 2026-07-31: 30.3 s at