fix: isolate destroy events to their owning windows

[ssrlive]

Filter bubbled wxEVT_DESTROY events by their source window before invalidating AUI managers, dispatching WindowEvents::on_destroy callbacks, or releasing Rust event closures. This prevents AUI floating-pane re-docking from invalidating the managed frame and dropping its callbacks.

[Copilot]

Pull request overview

This PR tightens wxEVT_DESTROY handling so that bubbled destroy events from child windows (notably wxAUI floating panes during re-docking) don’t invalidate unrelated AUI managers, fire WindowEvents::on_destroy callbacks on the wrong window, or prematurely release Rust event closures.

Changes:

• Filter wxEVT_DESTROY in AuiManagerBuilder so the manager invalidates only when its managed window is the destroy event source.
• Switch WindowEvents to a new macro that ignores destroy events whose event_object isn’t the target window.
• In the C++ event dispatcher, only release bound Rust closures on wxEVT_DESTROY when the handler’s owning window is the event source.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
rust/wxdragon/src/widgets/aui_manager.rs	Filters destroy invalidation to the managed window only.
rust/wxdragon/src/event/window_events.rs	Uses a new window-aware event handler macro for destroy filtering.
rust/wxdragon/src/event/macros.rs	Adds macro that suppresses bubbled destroy events from child windows.
rust/wxdragon-sys/cpp/src/event.cpp	Prevents destroy events from other windows from releasing this handler’s closures.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.