fix(sqlite): invalidate cached engine when VFS file changes

[chaliy]

Motivation

• The session-scoped SQLite engine cache reused engines keyed only by backend+path, allowing stale in-memory DB state to be read and flushed back after the VFS file was deleted or replaced.
• This could resurrect deleted data or overwrite a replacement file inside a Bash session, causing confidentiality/integrity issues within the VFS sandbox.

Description

• Before reusing a cached file-backed engine, compare the engine's snapshot_bytes() with the current ctx.fs.read_file(path) and force a reopen when the bytes differ or the read fails. (change in crates/bashkit/src/builtins/sqlite/mod.rs around the file-target path handling)
• Preserve existing semantics for :memory: targets (still ephemeral per-invocation). (no behavioural change to memory backend)
• Add two integration tests that cover deletion and replacement between exec() calls to guard against stale-cache resurrection and overwrite regressions. (added tests in crates/bashkit/tests/sqlite_integration_tests.rs)

Testing

• Ran the new integration tests filter with cargo test --features sqlite -p bashkit --test sqlite_integration_tests -- cached_engine_respects_, and both tests passed (2 passed, 0 failed).
• An earlier test run exposed an error which led to tightening the deleted-DB expectation; after the code change and test update the targeted integration tests passed.
• Build/test compilation completed locally for the modified test target during verification.

---

Codex Task

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	d10b2fe	Commit Preview URL	May 08 2026, 09:09 AM