[oscardvs]

Fixes #98.

SQLite never shrinks a -wal file by itself. A checkpoint copies the frames into the database and the next writer starts again at the front of the same file, so after one large transaction (a schema migration, a big build) the log keeps that size for good. #98 measured 1.08 GB beside a 3.6 GB index, unchanged for three weeks through daily updates and restarts.

Change (src/features/search/sqlite-index.ts):

• PRAGMA journal_size_limit = 64 MB on the index connection (it is per connection, so every open sets it). The first write after a checkpoint cuts the file back to 64 MB.
• A wal_checkpoint(TRUNCATE) at the end of open() and just before close(). Closing the last connection already deletes the log, but a sibling process sharing the data directory (a host probe, a second client, an index update run) makes this connection not the last one.
• The checkpoint runs with busy_timeout = 0, restored afterwards. Under the 10 s timeout it would stall an open behind a sibling's read or build. At 0 it returns busy: 1 at once, having copied what it could, and the next open or close reclaims the file. A failure never stops the index opening; corruption still reaches the existing sideline path.

Tests (tests/features/search-wal.test.ts, real node:sqlite files, a second connection kept open so no close is the last one):

• a log grown to 8 MB by a sibling is truncated to 0 when the index opens, and the data is intact;
• with the sibling mid-read, the open returns in well under the busy timeout and leaves the log, then the close truncates it once the read ends;
• the index connection reports journal_size_limit = 64 MB.

All three fail on main. Removing the busy_timeout = 0 line makes the second one take 10.2 s and fail.

Gates: typecheck, typecheck:tests, eslint on the touched files, and the full suite: 2731 passed. The only failures in the full parallel run were 5 s timeouts in tests/cli/entry.test.ts spawning tsx, which pass alone in 1 to 2 s per case and do not touch the index.