chore(deps): pin @harperfast/rocksdb-js to ~2.4.1 on v5.1

Moves the pin from ^2.3.0 to ~2.4.1 and the lockfile from 2.3.0 to 2.4.1.

2.4.1 is the 2.4-line backport of the cross-column-family transactional read
fix (rocksdb-js #717, backported in #732). TransactionHandle::get honored the
caller's dbHandleOverride on its synchronous block-cache-tier attempt but
dropped it in the async worker, falling back to the transaction's own column
family. All tables in a Harper database share one read transaction, so every
table after the first in a request was read through a foreign column family:
reads that hit the block cache were correct, reads that missed it silently
returned not-found. The failure was therefore intermittent and scaled with
cache residency — worst right after a restart, healing as traffic warmed the
cache. Where two tables share a key format a read could also hit in the
foreign column family and return another table's row.

Related: #1881.

Tilde, not caret, is deliberate. ^2.4.1 resolves to 2.5.0 at install time,
which would pull in the dedicated per-database commit thread, the
fd-limit-derived max_open_files default, and the VerificationTable epoch
rekey — none of which belong in a patch. ~2.4.1 holds 5.1.x on the 2.4 line.
main stays on ^2.5.0 for 5.2.

The lockfile moves with the pin because the lockfile is what ships: the
original exposure was ^2.3.0 with a 2.3.0 lockfile, which let the 5.1.22
image build against whatever npm resolved that day (2.4.0, with the bug).

Author: kriszyp

package-lock.json

@@ -170,7 +170,7 @@
 		"@fastify/cors": "^11.2.0",
 		"@fastify/static": "^9.1.3",
 		"@harperfast/extended-iterable": "^1.0.1",
-		"@harperfast/rocksdb-js": "^2.3.0",
+		"@harperfast/rocksdb-js": "~2.4.1",
 		"@turf/area": "6.5.0",
 		"@turf/boolean-contains": "6.5.0",
 		"@turf/boolean-disjoint": "6.5.0",