fix(emerg-shutdown): close leaked input-device fds and swallow SIGSYS

[maybebyte]

Summary

Two independent, low-severity correctness fixes in the emerg-shutdown
panic-key monitor (the statically-linked C daemon that watches input devices
and triggers emergency shutdown): a file-descriptor leak during device
enumeration, and a signal-ignore loop that misses SIGSYS.

Changes

• Close leaked input-device fds. Root cause: the device enumeration loop
  opens a descriptor for every /dev/input/eventN but only stores it for
  devices that support the panic-key combo. The two early-continue paths —
  non-key devices and keyboards lacking the panic keys — returned without
  closing tmp_fd, leaking one descriptor per non-qualifying device. The
  leak is bounded and one-time (the loop runs once at startup, not in the
  poll loop), but the fds are held for the daemon's lifetime and never
  reclaimed — the daemon never execs, so O_CLOEXEC does not cover them.
• Swallow SIGSYS in the signal-ignore loop. max_sig_num is 31, but the
  SIG_IGN loop used a strict <, covering signals 1–30 and never touching
  signal 31 (SIGSYS on Linux). The real-time loop starts at SIGRTMIN, so
  SIGSYS was ignored by neither and kept its default terminate disposition,
  contrary to the "Swallow all signals that we can." intent. Changed < to
  <=; the loop still stops before the glibc-reserved signals 32/33.

Testing

• Built via the project's own compile-emerg-shutdown after each commit —
  full hardening set (-Wall -Wextra -Werror=implicit -Wshadow … -static),
  clean build, valid ELF, no warnings-as-errors. -Werror=implicit confirms
  close() is properly declared (<unistd.h> is already included).
• Signal boundaries are platform-checkable: on glibc/Linux signal 31 is
  SIGSYS and is ignorable (sigaction(SIGSYS, SIG_IGN) returns 0), while 32
  and 33 return EINVAL, so <= correctly stops at 31.

Notes for reviewers

• Honest severity: both are low. The fd leak causes no exhaustion in practice
  (a handful of fds, once, well under RLIMIT_NOFILE); the SIGSYS change is a
  robustness/intent-alignment fix, not a hardening gain — SIGKILL and SIGSTOP
  are unblockable anyway, so anyone able to send SIGSYS can already kill the
  monitor. Its value is surviving an internally generated SIGSYS (e.g. a bad
  syscall).
• Split into two commits so each can be accepted independently.

[maybebyte]

AI assisted.