fix: disown boxed wrappers freed via *_free/*_unref methods (#429)

[romgrk]

Summary

Core fix for #429. A boxed/struct wrapper owns its backing memory and frees it on GC (gated by Boxed::owns_memory). When user code calls an introspected method that frees the instance itself — e.g. GLib.MainLoop's unref(), following the normal C idiom — node-gtk still thought it owned the memory and freed it again at GC. That double-free is a benign g_main_loop_unref: ref_count > 0 warning on lenient allocators, but a hard SIGSEGV during node's loop teardown when gi.startLoop() is active on libffi 3.5 (Ubuntu 26).

This is the general counterpart to the example fix in #431.

Fix

After an instance method whose C symbol ends in _free/_unref on a struct/union/boxed container, disown the wrapper (src/function.cc → new DisownBoxed in src/boxed.cc):

• clear owns_memory so the GC finalizer won't free it again;
• null the data pointer so later use fails cleanly rather than as a use-after-free.

Scoped deliberately:

• boxed/struct/union only — GObject lifetime is managed separately, and gtk_widget_destroy() & co. don't free the wrapper (hence _free/_unref only, not _destroy).
• Worst case is a leak, not a crash — if someone unref()s a multi-ref object without dropping the last ref, the wrapper simply won't unref at GC. Mixing manual refcounting with node-gtk's GC ownership was already unsupported.

Verified on Ubuntu 26.04 (rootless podman; libffi 3.5.2 / gir 1.86.0 / glib 2.88 / node 22)

The crashing pattern — gi.startLoop() + new GLib.MainLoop() + explicit loop.unref() + natural exit:

	crashes
before	30/30
with this fix	0/30

Plus a new regression test tests/conversion__boxed_explicit_unref.js (passes), and the full suite stays green locally (76 passing; only the pre-existing env require.js).

Note

Leaves the broader question (should ref/unref/free be hidden entirely?) untouched — this makes the common, idiomatic case safe with a minimal, scoped change.

🤖 Generated with Claude Code