Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/web/src/lib/server/datasets.ts`:
- Around line 213-229: The openNodeSqliteDatabase function currently requires
'node:sqlite' unguarded and will crash on pre-22.5 Node versions; wrap the
require('node:sqlite') call in a try/catch inside openNodeSqliteDatabase, detect
module-load errors (e.g. ERR_UNKNOWN_BUILTIN_MODULE) and either throw a clear,
actionable Error that states the minimum Node.js version required (22.5.0+) and
how to upgrade, or return a graceful fallback (e.g. a ReadonlyDatasetDb
implementation that throws meaningful errors on use), and update any
docs/comments to record the Node.js requirement; refer to
openNodeSqliteDatabase, DatabaseSync, and PreparedStatement when making the
change.
- Around line 251-261: The current error handling in the getDatasetDb function
catches failures from the better-sqlite3 loading fallback to node:sqlite, but if
openNodeSqliteDatabase also throws an error, it is not caught or logged. To fix
this, add a nested try-catch around the call to openNodeSqliteDatabase to catch
any errors it throws, log a detailed error message indicating both backends
failed to load the database for the given datasetId, and then rethrow the error
to ensure upstream awareness.

In `@apps/web/tests/lib/server/datasets.test.ts`:
- Around line 7-26: The test currently only mocks better-sqlite3
(betterSqlite3Factory / vi.mock('better-sqlite3')) so the fallback path to
node:sqlite is untested and can fail in CI; either mock 'node:sqlite' to provide
the same minimal API your production code expects (e.g., open/Database or
whatever exported functions your code uses) when betterSqlite3Factory is forced
to throw via mockImplementationOnce, or guard/skip the test when node:sqlite is
not present by detecting availability (try { require('node:sqlite') } catch { /*
skip */ }) and using Vitest's it.skipIf to skip the fallback test—update the
test that asserts "falls back to node:sqlite when better-sqlite3 fails to load"
to use one of these two approaches and reference betterSqlite3Factory and the
mocked module names ('better-sqlite3' and 'node:sqlite') so the CI reliably
exercises or skips the fallback.
- Around line 119-156: The test seeds the SQLite DB by calling
spawnSync('sqlite3', ...) which fails in CI because the sqlite3 CLI is not
present; replace that external call with an in-process DB creation using Node's
builtin sqlite API (or a lightweight Node sqlite library) to create the file at
dbPath and run the SQL statements used in the test (CREATE TABLE ...; INSERT
...), then remove the expect(seedResult.status).toBe(0) assertion and proceed
with writing registryPath and the rest of the test; keep references to dbPath,
registryPath, loadDatasetsModule, and the
betterSqlite3Factory.mockImplementationOnce stub so the test still simulates the
fallback path.

In `@tools/netflow-db/repair_mirrored_root_duplicates.py`:
- Around line 132-143: The unique index creation for
idx_processed_files_router_timestamp_unique and
idx_netflow_router_timestamp_unique is not protected and can raise
sqlite3.IntegrityError (rolling back the surrounding with conn: deletions);
modify the code to either wrap each conn.execute(...) that creates these indexes
in a try/except sqlite3.IntegrityError block (catch the exception and log/ignore
it) or move those conn.execute calls outside the transactional with conn: block
so index creation failures don’t undo the deletions—update the section that
executes the CREATE UNIQUE INDEX statements accordingly.

---

Nitpick comments:
In `@apps/web/src/lib/server/datasets.ts`:
- Around line 23-31: The PreparedStatement type should be converted to an
interface for consistency with ReadonlyDatasetDb; replace the type alias
PreparedStatement with an interface named PreparedStatement that declares the
same methods (get(...params: unknown[]): unknown and all(...params: unknown[]):
unknown[]), then keep ReadonlyDatasetDb.prepare(sql: string): PreparedStatement
and close(): void unchanged so the API surface remains identical.

In `@apps/web/src/routes/api/netflow/stats/`+server.ts:
- Around line 18-21: Add a brief inline comment above the getBucketStartQuery
function (which uses BUCKET_SIZES) that explains, step-by-step, what the SQL
expression does: convert stored unix timestamp to local datetime, compute the
start of the local day, calculate seconds elapsed since that start, divide by
the selected bucket size and multiply back to snap to the nearest bucket
boundary, and convert back to unix seconds (this explains the DST-aware
bucketing logic and purpose of the printf/CAST/strftime pieces so future
maintainers can quickly understand the transformation).