Summary

Issue #1763 threaded config.db.busyTimeoutMs through every call site that goes via openReadonlyOrFail() / openReadonlyWithNative(). However, several call sites open better-sqlite3 directly with new Database(dbPath, { readonly: true }), bypassing that helper entirely — so they never set PRAGMA busy_timeout at all (not even the hardcoded 5000ms default), let alone the user-configured value.

Call sites found

• src/features/snapshot.ts:103
• src/features/sequence.ts:183
• src/features/branch-compare.ts:205 and :246 (loadSymbolsFromDb, loadCallersFromDb)
• src/mcp/tools/find-cycles.ts:13
• src/mcp/tools/export-graph.ts:18
• src/cli/commands/info.ts:61
• src/db/repository/native-repository.ts:241 (#getFallbackDb, lazy fallback handle)

None of these call db.pragma('busy_timeout = ...') after opening.

Impact

On a busy/locked DB (e.g. a concurrent codegraph build holding the write lock), these call sites get SQLITE_BUSY immediately instead of waiting up to the configured (or default) timeout — inconsistent with the rest of the codebase's read-only DB access, and worse than even the pre-#1763 baseline (which at least had the hardcoded 5000ms default via openReadonlyOrFail).

Suggested fix

Route these through openReadonlyOrFail() / resolveBusyTimeoutMs() (or set the pragma directly with a resolved value) — same pattern already established by #1763.

Discovered while

Working on #1882 (threading config.db.busyTimeoutMs into the Rust NativeDatabase factories) — noticed branch-compare.ts's two new Database() call sites use this raw pattern while auditing that file's NativeDatabase.openReadonly() call for the fix.