chore(deps): bump lbug (kuzu) 0.16.0 -> 0.19.1

[pradeepmouli]

Summary

Bumps the lbug (kuzu-compatible graph DB) dependency from 0.16.0 to 0.19.1 across the three crates that pin it (infigraph-core, infigraph-cli, infigraph-docs), and adds a regression test that documents and guards the concurrency finding this bump resolves.

Why this was pinned at 0.16.0

A prior attempt to bump to 0.18.3 was paused after finding that a read-only Database::new() racing a live writer holding an open connection intermittently returned inconsistent results or crashed:

• On 0.16.0 this access pattern fails cleanly (a lock-contention-style error — safe).
• On 0.18.3/0.19.0 it could SIGSEGV, or surface a spurious "duplicated primary key" error even though no such duplicate exists in the committed data.

This was filed against the lbug project as LadybugDB/ladybug#766 (full repro included there — the same test added in this PR). It was triaged as a duplicate of tracking issue #666, and the actual fix landed in LadybugDB/ladybug#615 ("Fix read-only open during checkpoint from reading inconsistent state"), merged 2026-07-11 — first released in 0.18.2.

Verification

Rather than trust the changelog/issue-tracker resolution alone, this was re-verified empirically:

• crates/infigraph-mcp/tests/concurrent_writer_reader.rs (new in this PR): a writer thread holds one long-lived connection open and reindexes in a loop for ~6s; the main thread concurrently opens fresh read-only connections in a tight loop and queries for a symbol guaranteed to exist. Asserts every read is either correct or a clean Err — never wrong/missing data, and empirically never crashes.
• Run against 0.19.1: 0 SIGSEGV, 0 wrong results across repeated runs (up to several hundred concurrent read attempts against an active writer per run) — matching 0.16.0's original safe fail-closed semantics.
• No API breakage 0.16.0 → 0.19.1 — clean build, no call-site changes needed anywhere in the workspace.
• Full workspace build + cargo test --workspace pass cleanly on top of current main (verified in a fresh worktree off main, not just the fork's own branch state).
• cargo fmt --all -- --check and cargo clippy --all-targets -- -D warnings clean (pre-existing, unrelated clippy drift on main itself was confirmed via a separate bare-main check before drawing that conclusion, and is not touched by this PR).

A false alarm worth mentioning for reviewers

While testing this in a git worktree off main, compression_eval::phase2_compression_eval initially appeared to fail in a way that looked concerningly similar to the original concurrency finding (degenerate/tiny results). Investigation traced it to an unrelated auto-indexing quirk specific to running that test against a small git-worktree diff (it ended up indexing only the files changed by this PR's own two commits, not the full project) — confirmed by directly probing list_files/get_stats output and diffing against git log --name-only. It reproduces identically with or without this dependency bump and is a pre-existing test-environment sensitivity, not a regression from this change. Flagging it here in case it's useful, but it shouldn't block this PR.

Non-goals

This does not touch any lock/retry logic, error handling, or call sites — it is a pure version bump plus its own regression test.

[murari316]

Automated review (Fable, adversarially verified). Recommendation: approve-with-nits.

Pure dependency bump of lbug (kuzu) 0.16.0 -> 0.19.1 across the three pinning crates, plus a well-designed regression test reproducing the concurrent read-only-open-vs-active-writer scenario that blocked the previous bump attempt. Independently verified: the API surface used by the codebase is unchanged in 0.19.1; the wipe-vs-transient classifier string "Could not set lock on file" (lib.rs:67) still exists verbatim in 0.19.1's local_file_system.cpp so lock contention cannot be misclassified as corruption; and 0.19.1 explicitly reads storage versions 40-43, so 0.16.0-era DBs (v40) open in place with no forced wipe/reindex. Confidence: High. Recommendation: merge after considering the attempts>0 nit.

---

[MINOR] test-coverage — crates/infigraph-mcp/tests/concurrent_writer_reader.rs:150

The test can pass vacuously: it never asserts attempts > 0, so if the reader loop runs zero iterations (writer_done flips before the first read) or the writer thread exits early, both final assertions (wrong.is_empty() and correct + clean_errors == attempts) trivially hold with 0/0/0 and the test proves nothing. Add assert!(attempts > 0). Do NOT add assert!(correct > 0) — on Windows every concurrent read-only open may legitimately fail closed while the writer holds the DB, and that would be a CI-breaking flake across the 3-OS matrix.

Failure scenario: Writer thread panics or completes instantly after signaling ready (e.g. bundled_registry/init failure path changes, or a future refactor shortens the 6s loop); reader loop observes writer_done immediately, attempts = 0, test passes green while exercising nothing — a later lbug regression in this exact scenario ships undetected.

[NIT] concurrency — crates/infigraph-core/src/graph/store.rs:79

Pre-existing, not introduced by this PR, but this test raises its exposure: GraphStore::open_read_only calls kuzu::Database::new with no file-size preflight (the CLAUDE.md invariant references a size check 'see GraphStore::open', but neither open at store.rs:49-59 nor open_read_only at 74-82 has one — doc/code drift). The new test tight-loops this path against a DB file being actively checkpointed by the writer, which is exactly the torn-file scenario the invariant warns can make kuzu request a huge allocation and abort the whole process on Linux (before any Result exists).

Failure scenario: On a Linux CI runner, one of the hundreds of open_read_only calls lands on a torn/truncated file state mid-checkpoint; kuzu parses a bogus size field and aborts the test process. The failure presents as an unexplained SIGABRT flake rather than the clean error the test is designed to count, and gets retried/ignored instead of investigated.

[NIT] ci-cost — crates/infigraph-mcp/tests/concurrent_writer_reader.rs:86

Fixed 6s wall-clock writer loop plus an unthrottled reader busy-loop adds ~6s of pegged CPU per run across the 3-OS CI matrix, and adds one more embedded-DB-heavy integration test to a suite where CLAUDE.md already warns that default test parallelism can hit mmap/buffer-manager exhaustion from multiple embedded-DB test processes. Consider shortening the window (2-3s still yields hundreds of read samples at the stated rate) or reading the duration from an env var with a small default.

Failure scenario: Under default --test-threads on a loaded macOS runner, this test's sustained DB churn plus other kuzu-backed tests co-scheduled in parallel trips the known resource-contention failure mode in an unrelated test, producing a spurious red CI run.

[NIT] release-notes — crates/infigraph-core/Cargo.toml:21

Upgrade is one-way: lbug 0.19.1 writes storage version 43, which 0.16.0 cannot read (0.19.1's canReadStorageVersion accepts 40-43; 0.16.0 only its own). Rolling the dependency back after any 0.19.1 write will make every touched .infigraph/graph fail to open with a non-lock error, which init() will classify as persistent corruption and wipe+rebuild (full reindex). Forward upgrade is safe (verified: v40 DBs are readable by 0.19.1). Worth one line in the PR body/release notes so a hypothetical revert of this PR is understood to cost a fleet-wide reindex.

Failure scenario: This PR merges, users' watchers checkpoint their graphs at v43, then a later unrelated problem prompts reverting the bump; on next open every project's graph is wiped and rebuilt from scratch, appearing to users as lost index state and long re-index stalls.

Generated with Claude Code (Fable). Findings verified by an adversarial refute pass; false positives removed.