Opt-in destroy() alongside FinalizationRegistry? #239

I understand that v1 replaced the destroy() methods with FinalizationRegistry on purpose (#177, MIGRATING.md), and automatic cleanup is the right default. I'd like to ask whether an opt-in way to free an object immediately would be welcome alongside it, for workloads where finalization comes too late.

The problem. My use case is an application that shapes text with many user-supplied fonts in one process. FinalizationRegistry callbacks only run on an event loop turn after a garbage collection, so code that creates large objects without yielding keeps all of them alive, and the WASM memory fills up even though only one object is live at a time. Test case: make a Blob + Face + Font from the same 13 MB font data, drop them, and repeat 400 times. Results with upstream main plus #238:

So the garbage collector does run, but the memory only comes back after a macrotask turn, and even then the dropped 13 MB faces pile up to almost 1 GiB at the peak while only one face is live. The WASM memory never shrinks, so the process keeps that peak. A server that builds a face per request from a font cache, or a batch job that goes through a font collection in one synchronous pass, runs into this.

Without #238 it is worse: the failed allocation is not detected, the font data is copied over the start of the WASM memory, and the next finalizer that runs traps with RuntimeError: memory access out of bounds inside FinalizationRegistry.cleanupSome. The error is uncaught and exits Node.js with code 1. That PR makes the failure a catchable error, but the memory still cannot be released early.

Proposal. A strict addition, nothing changes for code that doesn't use it:

• destroy() on the classes that own native memory: Blob, Face, Font, FontFuncs, Buffer, DrawFuncs and PaintFuncs. It frees the native object right away and unregisters it from the registry (registry.register(obj, cleanup, obj) + registry.unregister(obj)), so the finalizer never runs a second time. Calling it again does nothing.
• Using an object after destroy() throws a JS error instead of passing a freed pointer to HarfBuzz.
• Optionally the same method as [Symbol.dispose](), so that using face = new hb.Face(blob); frees the face at the end of the scope, in keeping with the "nothing to remember" spirit of v1.

Objects that depend on others (a Face on its Blob, a Font on its Face) already hold their own HarfBuzz references, so destroying in any order is safe.

We already carry the core of this (destroy + unregister, idempotent) as a small local patch, tested in our application. If you're open to the idea, I'd be happy to send the full version above as a PR, with tests in the test suite and a README/MIGRATING update. If you'd rather keep it out of the API, that's fine too, and good to know.