Report native memory to the GC and add dispose function

[steckes]

Problem

Model, Processor, ProcessorAsync, Vad, VadAsync and Analyzer hold large native
allocations behind small JavaScript objects. V8's GC never saw that cost: heapUsed and
external barely moved, so the collector felt no pressure to reclaim dropped instances, and a
workload creating processors per unit of work ratcheted RSS up until the process was OOM-killed.

Changes

• Report each object's native footprint to V8 via napi_adjust_external_memory
  (new src/mem.rs): the footprint is reported at construction and returned exactly once when
  the object is destroyed, so GC pressure now reflects reality.
• dispose() on all six classes for deterministic cleanup without waiting for GC. After
  dispose, every method throws; repeat calls do nothing. Where work can be in flight it blocks
  until that work finishes. Model.dispose() unmaps the model file while objects created from
  it keep working; ProcessorContext/VadContext handles stay valid but no longer reach a
  live object.
• README "Memory management" section documenting cleanup timing (finalizers run on event-loop
  turns, RSS reflects the peak of live instances).
• New __test__/dispose.spec.ts (9 tests): dispose semantics, idempotency, model reference
  counting, and the dispose-vs-in-flight-analyzeAsync races.

[andresovela]

This doesn't make a lot of sense to me. I think this should just be Option<T>. Currently only the async APIs use a DisposableSlot<T>, but it feels like all API should use them. If anything, async APIs should own a Shared<DisposableSlot<T>> (still not happy with the Shared type, but let's leave that for later).

[steckes]

Yeah that makes sense, I got rid of the Mutex in Disposable Slot and just added it outside where it makes sense.

[andresovela]

LGTM. The comments need work but I think that's a broader issue, also in #22. We can merge this into next IMO.