fix(hytte-ui): destroy() the three remaining close()-teardown sites (#638)

[vibechoom]

Closes #638

The close()/destroy() distinction

Per GTK 4.22's own GIR docs:

• gtk_window_close — "Requests that the window is closed… similar to what happens when a window manager close button is clicked." A request, routed through close-request, which the default handler only turns into a real teardown for a realized window.
• gtk_window_destroy — "Drops the internal reference GTK holds on toplevel windows." The documented ref-dropping call, unconditionally.

hytte-ui's layer-shell builder deliberately never shows windows at construction (crates/hytte-ui/src/layer_window.rs:98: "wire up layer-shell, but don't show"), so the unrealized case is reachable here the same way #632 found it reachable in trollshell.

The three sites

• crates/hytte-ui/src/bar.rs — BarHandle::close() and impl Drop for BarHandle, both self.window.close() → self.window.destroy().
• crates/hytte-ui/src/popup.rs — close_catchers's win.close() → win.destroy(), tearing down the per-monitor dismiss-catcher windows.

Also corrected popup.rs's doc comments (on close_catchers, and the test-module preamble) — they already asserted the destroy-specific "removes it from GTK's window list" semantics while the code only called close(). Now destroy() is what's called and what's documented, so the comments are true rather than aspirational.

close-request grep result — the "check before changing" site

grep -rn "close_request\|connect_close_request" crates/ trollshell/ finds exactly one hit: crates/trollshell-control-center/src/main.rs:113, on the control-center's own adw::ApplicationWindow (its handler just cancels a poll timer on close). That window has no relationship to BarHandle or popup.rs's catcher windows — it's a separate binary that never links the shell.

I also grepped for direct callers of BarHandle::close() (as opposed to the self.window.close() call inside its own impl): none exist in trollshell/ or crates/. BarHandle is dropped (via Vec<BarHandle> clearing in main.rs on monitor rebuild) far more than it's explicitly .close()'d.

Conclusion: nothing relies on a close-request handler running for either the Bar window or a popup dismiss-catcher. Changed all three sites unconditionally, per the issue's expected outcome.

Test feasibility

hytte-ui does have a system-tests feature bucket (gated GTK unit tests under xvfb-run, crates/hytte-ui/Cargo.toml:16), and popup.rs already has an existing test (close_catchers_drains_and_destroys_idempotently) using the weak-ref-upgrade-after-close()ing pattern — it still passes unchanged, since its windows are present()-realized (both close() and destroy() tear down a realized window; this test doesn't discriminate the two, it just keeps regression-covering the teardown mechanism itself).

The genuinely new, previously-uncovered case is BarHandle's Drop on an unrealized window (the issue's "more interesting" site) — so I added bar::tests::drop_destroys_an_unrealized_bar_window, mirroring popup.rs's technique: construct a bare gtk::Window (never .present()'d, so unrealized), wrap it in BarHandle via the private struct literal (the test module is a child of bar), drop the handle, iterate the main context, and assert the weak ref no longer upgrades.

I did not take this on faith — I verified it discriminates before finalizing: I temporarily reverted the Drop impl to close() and reran the test under xvfb-run; it failed with exactly the panic message asserting the leak. Restoring destroy() makes it pass again. So this is a real regression test, not a tautology that would pass either way.

Local run (via nix shell nixpkgs#xvfb-run layered on the devShell, since neither is in the devShell or workspace buildInputs — matching flake.nix's own system-tests check):

xvfb-run -a cargo test -p hytte-ui --features system-tests
# 105 passed; 0 failed (includes bar::tests::drop_destroys_an_unrealized_bar_window
# and popup::tests::close_catchers_drains_and_destroys_idempotently)

Live-verify note

A lack of change is the pass condition here: bars and popup dismiss-catchers should still disappear correctly in the same situations they always did.

• Multi-monitor hot-plug/kanshi profile switches: bars on removed monitors should still disappear (no visible bar surviving a monitor teardown), and rebuilt bars on remaining/re-added monitors should behave normally.
• Popup dismiss-catchers: opening a bar-chip popup, then dismissing it (click-outside, Escape, autohide, or scroll) should still make the full-screen catcher windows disappear on every output — no leftover invisible click-eater.
• Nothing here should be observably different from before the change, since every site was already realized in the popup case and destroy() is a superset of what a realized-window close() achieves; the BarHandle::Drop path is the one place behavior could differ (an unrealized bar handle dropped mid-setup now actually tears down instead of silently no-op'ing), which has no normal-operation user-visible symptom to watch for beyond "nothing leaks."

Gates run

• unset RUSTC_WRAPPER && cargo clippy -p hytte-ui --all-targets --features system-tests -- -D warnings — clean.
• cargo test -p hytte-ui — 46 passed, 0 failed (hermetic bucket).
• xvfb-run cargo test -p hytte-ui --features system-tests — 105 passed, 0 failed.
• nix fmt twice — 0 files changed both times.