Unit test red on main: 'Audit log: can handle separate subscriptions on separate dbs' (2 == 1, duplicate/leaked subscription event)

### Bug Summary

The resources unit test **`Audit log › can handle separate subscriptions on separate dbs`** (`unitTests/resources/auditLog.test.js:502`) fails on `main`:

```
AssertionError [ERR_ASSERTION]: 2 == 1
at Context. (unitTests/resources/auditLog.test.js:502:11)
```

The test creates `DB_COUNT = 3` tables on separate databases (`test-subscribe0/1/2`), subscribes to each, `put`s a single record into each, waits for the first `data` event per table, then asserts each subscription received **exactly one** event. One subscription receives **2** events for its single put — so this is either a duplicate `data` delivery or cross-database subscription event leakage.

### Reproduction

- Node **v22.21.1**, RocksDB (default storage engine), macOS.
- Fails on a clean checkout of `main` (commit `266d5d8b`), **both**:
- in isolation: `npx mocha unitTests/resources/auditLog.test.js` — failed 5/5 runs (17 passing, 1 failing each).
- in the full suite: `npm run test:unit:resources` — `685 passing … 2 failing` on clean main (the other failure being #1137).

```
1. Check out main.
2. npm run build
3. npx mocha unitTests/resources/auditLog.test.js
4. Observe `can handle separate subscriptions on separate dbs` failing with `2 == 1`.
```

### Notes / scope

- This is **separate from #1137** (the commutative-op double-apply). Surfaced while triaging #1137: clean `main` actually has two red tests in the resources suite, not one. The #1137 CI run (https://github.com/HarperFast/harper/actions/runs/26961236701) reported only the #1137 failure with this test green — so this one appears **environment/load-sensitive** (deterministic on this machine, evidently passing on CI).
- The test was added in `f4742911` (Test the separate db subscriptions) and most recently changed in `ad7194db` (replace the fixed `delay(40)` with an event-driven wait). The event-driven wait resolves on the *first* `data` event but then asserts the total count is 1 after `Promise.all` — so an extra/duplicate event on any one subscription trips it.

### First triage question

Is one subscription receiving a **duplicate** `data` event for its own single `put`, or an event **leaked from another database's** table/log? The audit/transaction-log subscription machinery (`RocksTransactionLogStore` per-log iterators, `listenToCommits`) is the place to look — a subscription keyed to one db's log picking up another db's commit, or re-emitting a single commit twice, would both produce `2 == 1` here.

---

🤖 Generated with [Claude Code](https://claude.com/claude-code)