v3.38.1 — memory search truncation + persistence honesty fixes
Fixes
#2982 / #2976 — memory search silently dropped entries on large corpora. bridgeSearchEntries() and bridgeSearchHNSW() pre-ranked the memory corpus with an unordered LIMIT 1000 / LIMIT 10000 before BM25/embedding scoring ever ran. Without an ORDER BY, SQLite returns rows in arbitrary storage order (insertion order on a fresh table) — so on any corpus over the limit, the newest entries never reached scoring at all, regardless of how well they matched the query. Both paths now order by updated_at DESC before truncating, matching the pattern bridgeListEntries() already used.
Verified with a stash-based A/B on a 1005-row fixture: the exact same search returns zero results without the fix, recalls correctly with it.
#2968 — memory store claimed success even when the write might not persist. On the sql.js fallback driver (engaged when better-sqlite3's native binding never got built — e.g. a skipped optionalDependency postinstall), the post-write wal_checkpoint(PASSIVE) checkpoint throws Invalid PRAGMA command every time and was silently swallowed as "non-fatal." bridgeStoreEntry() now distinguishes that specific failure signature from an ordinary busy/non-WAL pragma failure and surfaces it as persistWarning, which memory store prints instead of an unconditional green "Data stored successfully."
Both fixes are scoped to ruflo's own CLI bridge layer — no changes to the external agentdb/better-sqlite3 packages.
Also investigated, not changed
From the same triage pass: #2969 (--version hang), #2970 (witness verify soft-pass), and #2967 bug 1 (uptime unit mismatch) were all checked with a direct repro against current main and none reproduced — --version exits cleanly and fast, verify.mjs already exits 2 on a forced source-only checkout, and the uptime math is already correct post-#2235(B). No speculative fixes shipped for those.