fix(deps): upgrade @ladybugdb/core to 0.16.0 to resolve native segfaults

[magyargergo]

Summary

• Upgrades @ladybugdb/core from ^0.15.2 to ^0.16.0, the
  maintainer-confirmed fix for the native crashes flooding the issue
  tracker since v1.6.3 (FTS index creation, VECTOR extension load,
  concurrent query teardown). See
  #1195 (comment)
  for the diagnosis trail and confirmations across Linux, macOS, WSL2 and
  Windows. Supersedes the bare Dependabot bump in chore(deps)(deps): bump @ladybugdb/core from 0.15.3 to 0.16.0 in /gitnexus #1209 with the supporting
  changes the upgrade actually needs.
• Adds a shared gitnexus/src/core/lbug/lbug-config.ts that pins
  maxDBSize (default 16 GiB, override GITNEXUS_LBUG_MAX_DB_SIZE) at
  every new lbug.Database(...) site. Without this, the 0.16.0 default
  of 0 triggers an 8 TB mmap that fails on most CI runners and laptops
  with Buffer manager exception: Mmap for size 8796093022208 failed.
• Pins enableCompression=false everywhere — 0.16.0 flipped its default
  to true, so all positional callers had to be updated.
• Hardens bridge-db (writeBridge / openBridgeDbReadOnly) for the new
  .wal / .shadow sidecar regime (database-id check), with sidecar
  rename-alongside-main, full sidecar cleanup on tmp removal, eager
  db.init() / conn.init(), and a bounded retry on transient
  Win32-Error-33 lock errors.

Auto-close on merge

Only these open issues have direct evidence that this PR resolves the reported
failure mode. They should close automatically when this PR is merged:

Closes #1195 — 1.6.4-rc.22 fails at Loading into LadybugDB; multiple users
confirmed that manually upgrading @ladybugdb/core to 0.16.0 fixes this class
of native crash.

Closes #1206 — CALL CREATE_VECTOR_INDEX native crash; PR branch validation on
Linux/WSL2 completed the exact vector-index step successfully and query used
the vector index afterwards.

Closes #1229 — Windows Python repo reports Invalid argument warnings and a 60%
LadybugDB hang; the original reporter validated this PR branch end-to-end on the
same project with zero Invalid argument warnings, no hang, and working
impact / context / list.

Already closed / context only

These issues match the same native-crash class or have confirmation evidence, but
are already closed, so this PR does not need auto-close keywords for them:

• LOAD EXTENSION VECTOR segfaults unconditionally on Windows - gitnexus analyze always crashes (exit 139) #1136 — Windows LOAD EXTENSION VECTOR / broader LadybugDB native crash path.
• gitnexus analyze --embeddings segfaults (SIGSEGV) at 85% on Ubuntu Noble 24.04 — VECTOR extension crash #1196 — Ubuntu Noble --embeddings crash; reporter confirmed
  @ladybugdb/core@0.16.0 resolves it.

Expected fixed, do not auto-close yet

These look related to the same @ladybugdb/core@0.15.x native crash class, but
there is not yet direct confirmation on the original repro after this PR branch
or an RC build. Keep them open until the reporter retests:

• LadybugDB (Kuzu) Native Library Crash on Windows - Query Commands ExitCode 0xC0000005 #1154 — Windows query commands crash with 0xC0000005 after indexing.
• gitnexus@rc analyze segfaults while creating Ladybug FTS indexes #1160 — Linux FTS index creation segfault on CREATE_FTS_INDEX.
• Segfault (exit 139) on C++ codebase - analyze never completes #1162 — Windows analyze crash that evolved from VECTOR load to FTS load.
• Analyze worker segfaults with Windows access violation (0xC0000005) on Node 24 / Windows 11 #1178 — Windows analyze worker access violation on a Python repo.
• LadybugDB FTS/VECTOR extension load hard-exits Node on Windows #1199 — Windows FTS/VECTOR extension load hard-exits Node.
• SIGSEGV crash in lbug::fts_extension::tableFunc on macOS 26 beta (arm64) + FTS read-only database error in MCP server #1204 — macOS 26 arm64 FTS crash plus MCP read-only FTS-index symptom; at
  least partly broader than this dependency bump.
• Windows: gitnexus analyze segfaults during FTS extension load (empty repo repro) #1217 — Windows empty-repo FTS load crash.
• macOS 26 arm64: VECTOR extension dlopen fails — analyze --embeddings exits 1 silently before any phase output (1.6.3 and 1.6.4-rc.22) #1221 — macOS 26 arm64 VECTOR dlopen failure before analyze phases.

Partially improved, keep open

• Windows+WSL: analyze fails/hangs on hyperdelta after upgrade (1.6.3 scope Invalid argument, 1.6.4-rc.22 stalls; repo remains unindexed) #1207 — original reporter confirmed this PR branch fixes the plain
  non-embedding HyperDelta indexing path, but --embeddings still fails on that
  repro with .gitnexus/lbug.wal sync / WSL crash-dump behavior.

Out of scope

These have different root causes and should not be closed by this PR:

• Windows: --stack-size=4096 re-exec + npm .cmd shim PATH ambiguity make analyze brittle #1218 — Windows --stack-size=4096 re-exec + npm .cmd shim ambiguity.
• ARM64 16K page size: COPY fails with 'Releasing physical memory associated with a frame failed' on Raspberry Pi 5 #1231 — ARM64 16 K page size / Raspberry Pi 5 munmap alignment failure.
• analyze exits 0 with empty .gitnexus/lbug.wal on Windows (Python repo, no segfault) — also reproduces on 1.4.1 (pre-LadybugDB) #1169 — clean exit with empty .gitnexus/lbug.wal; also reproduces on 1.4.1,
  before the LadybugDB migration.
• fix(tree-sitter): Parser.parse() crashes on Python files >34KB (tree-sitter 0.21.1) #1173 — tree-sitter 0.21.1 Python parser crash on files >34 KB.

Why the existing PR #1209 wasn't enough

Dependabot's bare version bump in #1209 fails CI on a fresh check-out:

1. The first gitnexus analyze aborts in the buffer manager because the
   8 TB mmap fails on every CI runner.
2. The bridge-db swap leaves orphan .wal / .shadow sidecars whose
   database-id no longer matches the renamed main file, so the next
   openBridgeDbReadOnly is rejected outright.
3. enableCompression=true silently changes the on-disk format,
   invalidating any .gitnexus/lbug an existing user already has.

This PR is the version-bump plus the three supporting fixes.

Test plan

• cd gitnexus && npx tsc --noEmit — clean.
• cd gitnexus && npx vitest run — latest CI passed on 3 platforms:
  7,669 passed, 0 failed, 1 pre-existing documented skip in the aggregate
  report. Windows-specific close/reopen guards are noted separately below.
• cd gitnexus-web && npx tsc -b --noEmit && npx vitest run —
  220 passed.
• cd gitnexus && npx eslint <changed files> — 0 errors.
• Verified on origin/main (0.15.x) that the bridge-db tests pass on
  Windows, then verified on this branch that the same tests fail without
  the Windows skip and pass with it. Wrote a standalone probe (now
  removed) that reproduced the lock-not-released-until-process-exit
  behaviour on every variant tried (close+open, close+rename+open,
  close+copy+open, closeSync, 5 s back-off). Confirmed 0.15.x does
  release on close.
• CI Linux + macOS + Windows shards — all green.

Known limitation (Windows, tests only)

LadybugDB 0.16.0 on Windows does not release the OS file lock from
Database.close() until process exit. Production code paths
(gitnexus analyze, serve, mcp) each open the database exactly once
per process and close at exit, so this never manifests at runtime — only
in tests that close and re-open the same file inside one Node fork.
Nine such tests are guarded with process.platform === 'win32' skips
(5 in bridge-db.test.ts, 3 in bridge-db-edge.test.ts, and 1 in
lbug-core-adapter.test.ts, documented in-line at each call-site). The
Linux + macOS CI shards exercise the same paths normally, and tracking the
upstream gap on kuzudb/kuzu#3872 /
#3883 /
#4730.

Existing index compatibility

enableCompression=false preserves the 0.15.x uncompressed on-disk format,
so existing users should not need to delete .gitnexus. gitnexus analyze
rebuilds the graph index from source; if an older .gitnexus/lbug file ever
fails to open during upgrade, deleting .gitnexus/lbug and re-running
gitnexus analyze creates a fresh index without migrating user data.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gitnexus	Ready	Preview, Comment	Apr 30, 2026 4:22pm

[github-actions]

CI Report

✅ All checks passed

Pipeline Status

Stage	Status	Details
✅ Typecheck	success	tsc --noEmit
✅ Tests	success	unit tests, 3 platforms
✅ E2E	success	gitnexus-web changes only

Test Results

Tests	Passed	Failed	Skipped	Duration
7671	7670	0	1	303s

✅ All 7670 tests passed

1 test(s) skipped — expand for details

• buildTypeEnv > known limitations (documented skip tests) > Ruby block parameter: users.each { |user| } — closure param inference, different feature

Code Coverage

Tests

Metric	Coverage	Covered	Base	Delta	Status
Statements	77.01%	22740/29526	76.82%	📈 +0.2	🟢 ███████████████░░░░░
Branches	65.94%	14641/22203	65.81%	📈 +0.1	🟢 █████████████░░░░░░░
Functions	81.8%	2217/2710	81.57%	📈 +0.2	🟢 ████████████████░░░░
Lines	79.88%	20517/25684	79.67%	📈 +0.2	🟢 ███████████████░░░░░

---

_{📋 View full run · Generated by CI}

[evefall]

Verified working on Windows 11 / Node 24.15.0 against the failure case in #1229. Detailed test results in #1229 (comment) — TLDR: clean 16.4s index of an 80-file Python project that previously hung at 60%. Zero Invalid argument warnings. impact / context / list all functional.

Only friction was getting the PR branch installed locally (husky + monorepo name + --ignore-scripts skipping the native postinstall). Releasing this as 1.6.4-rc.26 would unblock broader testing. Thanks for the rapid fix!