Fix stale query timeout guards interrupting unrelated queries

[penberg]

The TimeoutGuard held by RowsIterator was only released when the JS garbage collector collected the native object. In a tight loop of stmt.all() calls (which uses iterate() internally), exhausted iterators would pile up unreachable but not yet GC'd. When their timeout deadline fired — potentially hundreds of milliseconds after the query finished — conn.interrupt() would kill whatever unrelated query happened to be running at that moment, producing spurious SQLITE_INTERRUPT errors well below the configured timeout.

Fix: eagerly release the TimeoutGuard as soon as the iterator is exhausted (next() returns None), encounters an error, or is explicitly closed via the iterator return() protocol (break/throw in for...of).

• Rust: change _timeout_guard: Option<TimeoutGuard> to Mutex<Option<TimeoutGuard>> so close() and next() can both release the guard through a shared reference. Expose close() via napi.
• promise.js / compat.js: wrap the native iterator with an idempotent close helper and implement return() for early-termination cleanup.
• Add integration test that reproduces the original bug: 100 sequential stmt.all() calls with a 500ms timeout, each finishing in ~115ms, which reliably triggered stale-guard interrupts before this fix.