commit-teardown.test.ts crashes with SIGABRT (mutex lock failed: Invalid argument) on Deno macOS CI

## Summary

`test/commit-teardown.test.ts` ("Async commit completion vs. worker env teardown") crashes
the repro child process with `SIGABRT` on **Deno + macos-latest** CI, with:

```
libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
```

This is a native (C++) crash — `pthread_mutex_lock` returning `EINVAL`, which on libc++'s
`std::mutex` means the mutex was already destroyed (or never initialized) when a thread tried
to lock it. It reproduces in the fixture's normal worker-terminate-mid-commit-stream scenario
(`test/fixtures/fork-commit-teardown.mts`), i.e. exactly the lifecycle race the test exists to
catch (env teardown racing the shared per-database commit thread) — just not the specific
env-cleanup-hook / commit-completion-tsfn race the test's own comment describes, since that
path is guarded by `commitMutex` (see AGENTS.md "Commit execution"). Something else in the
teardown path is locking a mutex whose owning object has already been (or is concurrently
being) destroyed.

## Evidence this is pre-existing and unrelated to any single PR's diff

Same test, same exact crash message, same "iteration=0" first-iteration failure, across three
unrelated PRs in the last 24h — none of which touch commit-teardown/commit-thread code:

| PR / branch | run | `ROCKSDB_JS_COMMIT_THREAD` mode | job |
|---|---|---|---|
| #744 `fix/park-timeout-coordinated-retry` (VT park-timeout only) | [30719858670](https://github.com/HarperFast/rocksdb-js/actions/runs/30719858670/job/91421710769) | `'2'` | Test on Deno (macos-latest) |
| `dependabot/npm_and_yarn/patch-b7a1a6d5c6` (dependency bump) | [30665452962](https://github.com/HarperFast/rocksdb-js/actions/runs/30665452962/job/91271278462) | `'default'` | Test on Deno (macos-latest) |
| `fix/dropped-cf-write-poisons-env` | [30663991359](https://github.com/HarperFast/rocksdb-js/actions/runs/30663991359/job/91266532061) | `'2'` | Test on Deno (macos-latest) |

Hits both commit-thread modes (`default` single-lane and `2` two-lane), so it's not specific to
the two-lane pipeline. All three are macOS + Deno only in the runs observed so far (Node and Bun
macOS jobs passed alongside it in the same CI run for #744), though the fixture only runs 1
iteration on macOS/Windows (vs. 2 on Linux Node — see the test's `iterations` comment), so a
lower hit-rate on other runtime/OS combos on this evidence alone doesn't rule them out.

## Likely relation to other open lifecycle issues

Same theme as #695 (env-cleanup-hook/registry teardown races) and #741 (worker-env teardown
corrupting the shared `DBDescriptor`'s transactions under concurrent commits) — a third distinct
symptom in the same "shared `DBDescriptor` survives one env's teardown while another env is still
using it" hazard class, this time inside `CommitWorker`/commit-completion teardown rather than
`OpenDB` (#695) or `TransactionHandle`/RocksDB txn destruction (#741). Filing separately since the
crash site/mutex involved hasn't been isolated yet — needs a debug build + the ASan/Guard Malloc
procedure in AGENTS.md ("Debugging native heap corruption") to pin down which mutex.

## Suggested next step

Root-cause with ASan (Linux) or Guard Malloc (macOS) per AGENTS.md, looping
`fork-commit-teardown.mts` directly (bypass vitest to get a clean native stack). Until then, a CI
retry stopgap for the affected job (matching the existing windows-latest retry pattern, precedent
in #695/#742) keeps this pre-existing race from blocking unrelated PRs.

Reported by Claude Sonnet 5 on behalf of @kriszyp, while triaging PR #744's CI failure.

Start with test/commit-teardown.test.ts and test/fixtures/fork-commit-teardown.mts, then read the Commit execution and Debugging native heap corruption sections of AGENTS.md. Run the fixture directly under the suggested ASan or Guard Malloc procedure to obtain a native stack and identify which mutex is destroyed or used concurrently. Done means the teardown race is isolated and the macOS Deno crash no longer reproduces.

Written by the indexing model from the issue text.