refactor(database): hand the sweeps a client instead of a singleton

[Artmann]

Four modules under src/main — the two retention sweeps, the query
reconciliation, and the span writer — reached SQLite by importing the
database value out of src/database/index.ts, which builds a client against
process.cwd()/squeal.sqlite3 the moment the module is evaluated. Every other
service goes through AppDatabase, whose header says so in as many words.

The client is an argument now:

deleteExpiredQueries(client, retentionDays?)
deleteExpiredSpans(client, options?)
markInterruptedQueries(client)
writeSpans(client, records)          // the default is gone

Nothing under src/main evaluates src/database/index.ts any more — the
remaining references are all import type, and the one value import left in
the repository is src/server/services/app-database.ts, which is the intended
owner.

What it buys

The tests the issue asked for are the ones the singleton made impossible: run
a sweep against database A while B exists, and assert B was left alone. Four
such cases, plus two covering the seams the first pass left open (boot.ts
was a changed call site no test reached; in-memory-database.ts is what every
test now leans on for isolation and nothing asserted anything about it).

Deleted with them: src/test/api-test-helper.ts, its self-test, and
database-mock-import-order.test.ts. Those existed to make the "register the
vi.mock before importing the module under test" hazard survivable and to keep
the paragraph explaining it honest. grep -rn "vi.mock('@/database" now
returns nothing repo-wide, so the hazard is gone rather than documented.

The two vi.mock calls in retention.test.ts stay: that file tests the fiber
around the sweeps — order, schedule, and what a failure does to both — so it
needs sweeps that resolve on command. The comment above them says that now,
instead of naming this issue.

Verification

Full suite 1416 passed, 2 failed — both pre-existing on main
(sqlite-adapter.test.ts > connects and executes SELECT 1, and the
DatabaseForm.test.tsx post-change-verdict flake). Both typecheck projects
exit 0; ESLint 0 errors.

Mutation: 9 defects killed, including each of the three sweeps restored to the
singleton (the pre-change code exactly), the schedule giving the client to only
one of its two sweeps, boot reconciling the singleton, the writer writing to a
database of its own, and the test helper either skipping the schema or handing
every caller the same database. A tenth — omitting the client at a call site —
is rejected by tsc and also fails trace-store.test.ts at runtime. Two
non-defects survived (renaming a parameter, reading the options before the
client).

Reviewed with fresh context, which re-ran all ten independently. One thing it
raised and I am carrying forward rather than fixing here: restoring the
writeSpans default is a type-valid, test-invisible edit, so a
no-restricted-imports rule naming @/database outside app-database.ts
would make the invariant enforceable rather than conventional. Mutants 1-3 and
6 show the suite rejects every realistic regression today, so that is
belt-and-braces, not a gap.

Closes #85

[github-actions]

React Doctor found 1 new issue in 1 file · 1 warning · score 90 / 100 (Great) · 1 fixed · vs main

1 warning

src/main/tracing/trace-retention.ts

• ⚠️ L39 Sequential independent awaits server-sequential-independent-await

_{Reviewed by React Doctor for commit 55b4c11. See inline comments for fixes.}

[Artmann]

Not applying this one — I think it is a false positive here, and I measured it rather than assuming.

The two DELETEs cannot overlap. drizzle(databaseFilePath) builds a local libsql client, whose driver is synchronous and runs on the main process's event loop, and SQLite serializes writes on a connection regardless. So Promise.all describes a concurrency the database will not honour — the statements queue either way.

Measured on an in-memory app database with 40,000 spans, three runs each:

	run 1	run 2	run 3
sequential	24ms	22ms	22ms
Promise.all	23ms	22ms	26ms

Within noise, and both forms leave the same 2,000 rows behind and report the same 18,000 deleted.

The other half is context: the rule's premise is "your users wait twice as long", but nothing is waiting on this. deleteExpiredSpans has one caller — the daily retention fiber in src/server/retention.ts, which sweeps once at boot and then once every 24 hours. That file already documents the synchronous-driver constraint at L29 as the reason it carries no per-sweep timeout either.

I have added a comment at the call site (55b4c11) recording the measurement, so the next reader does not have to re-derive it.