[rymalia]

Bun (ubuntu-latest) now fails in the same two tests on unrelated PRs, #1085, #1090 and #1091, all of which ran on Bun 1.4.4 because the workflow installs bun-version: latest. main last passed this job on Bun 1.4.3.

• doctor vector sampling > the doctor check verifies large documents with duplicate paths within a 32 MiB SQLite budget
• Embedding batching > legacy fingerprint adoption reads one copy of a body shared by 200 active paths within a 16 MiB SQLite budget

Both assert limitBinds === true, meaning SQLite's hard_heap_limit is enforced, under Bun on Linux. That guard was added in #1020 so these tests would "fail under Bun if the limit ever stops applying rather than passing without it". The limit has now stopped applying, so the guard did its job.

Cause

Bun 1.4.4 (oven-sh/bun#45304, which consolidates the SQL drivers) turns SQLite's memory statistics off once, before the first open:

// src/jsc/bindings/sqlite/JSSQLStatement.cpp, Bun__initializeSQLite()
// Statistics put one process-wide mutex around every malloc and free.
sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0);

Without memory statistics, PRAGMA hard_heap_limit never fails an allocation. Bun's own suite now asserts that (test/js/bun/sqlite/sqlite.test.js: "PRAGMA hard_heap_limit does not fail allocations"). The call also runs from Database.setCustomSQLite(), so loading a different SQLite library doesn't bring the limit back. The build defines in scripts/build/deps/sqlite.ts are the same in 1.4.3 and 1.4.4, so this is a runtime change, not a build flag.

I checked it on macOS with the Homebrew SQLite that src/db.ts loads through setCustomSQLite, using heapLimitBinds' own probe:

Bun	SQLite	limitBinds
1.4.3	Homebrew 3.54.1	true
1.4.4	Homebrew 3.54.1	false

Change (tests only)

• test/_helpers/heap-limit.ts: exports bunSqliteTracksMemory, which is isBun && !Bun.semver.satisfies(Bun.version, ">=1.4.4"), with a comment pointing at the Bun change.
• The two Linux-under-Bun checks now expect limitBinds to equal bunSqliteTracksMemory, where they used to expect true. The comparison is exact in both directions: if a later Bun turns the statistics back on, the check fails again, which is the cue to bound the version range.
• Comments that said the limit binds under Bun now say "before 1.4.4".

The workflow stays on bun-version: latest. Pinning 1.4.3 would make the job green, but 1.4.3 predates the Brotli decoder fix that shipped in 1.4.4: the patched FORMAT_BLOCK_SWITCH handling appears 0 times in the 1.4.3 binary and 3 times in 1.4.4. It would also only postpone the failure, since the change in Bun is deliberate.

What this leaves open

None of qmd's runtimes now enforces these SQLite budgets: better-sqlite3 is built with SQLITE_DEFAULT_MEMSTATUS=0, and Bun ≥1.4.4 turns statistics off. The four heap-budget tests from #978, #995 and #1020 still check their results, but they no longer prove the memory bound. If that bound matters, the tests could measure it independently of SQLite, for example by having the worker report its peak RSS (VmHWM in /proc/self/status on Linux) and checking it against the budget. That would hold on both Node and Bun. I left that out to keep this PR to the CI fix, but I'm happy to follow up if you'd like it.

Verification

• npx tsc --noEmit -p tsconfig.json and npx oxlint: clean
• bunSqliteTracksMemory matches the limitBinds each worker actually reports on macOS with Homebrew SQLite: true under Bun 1.4.3, false under Bun 1.4.4. Under Node it is false, because isBun short-circuits it.
• The changed check runs only under Bun on Linux, so this PR's own Bun (ubuntu-latest) job is its real test.