fix: handle monitor hotplug to survive suspend/resume (v0.6.9)

moonlock crashed with segfault in libgtk-4.so after suspend/resume when
HDMI monitors disconnected and reconnected, invalidating GDK monitor
objects that statically created windows still referenced.

Replace manual monitor iteration with connect_monitor signal (v1_2) that
fires both at lock time and on hotplug. Windows are now created on demand
per monitor event and auto-unmap when their monitor disappears.

README.md

@@ -8,14 +8,13 @@ Part of the Moonarch ecosystem.
 - **ext-session-lock-v1** — Protocol-guaranteed screen locking (compositor keeps screen locked on crash, `exit(1)` in release if unsupported)
 - **PAM authentication** — Uses system PAM stack (`/etc/pam.d/moonlock`) with 30s timeout and generation counter
 - **Fingerprint unlock** — fprintd D-Bus integration with sender validation, async init (window appears instantly), `pam_acct_mgmt` check after verify, auto-resume on transient errors
-- **Multi-monitor** — Lockscreen on every monitor with shared blur and avatar caches
+- **Multi-monitor + hotplug** — Lockscreen on every monitor with shared blur and avatar caches; monitors added after suspend/resume get windows automatically via `connect_monitor` signal
 - **GPU blur** — Background blur via GskBlurNode (downscale to max 1920px, configurable 0–100)
 - **i18n** — German and English (auto-detected)
 - **Faillock warning** — Progressive UI warning after failed attempts, PAM decides lockout
 - **Panic safety** — Panic hook logs but never unlocks (installed before logging)
 - **Password wiping** — `Zeroize` on drop from GTK entry through PAM FFI layer
 - **Journal logging** — `journalctl -t moonlock`, debug level via `MOONLOCK_DEBUG` env var
-- **Lock-first architecture** — Wallpaper loaded after `lock()` so disk I/O never delays lock acquisition
 
 ## Requirements