fix(bindings): derive sqlite limits from host time and memory caps

[chaliy]

Motivation

• The Python/JS bindings enabled the in-process SQLite builtin with SqliteLimits::default(), which allowed large result materialisation and rendering to bypass host ExecutionLimits and risk in-process DoS.
• The change aligns SQLite budgets with the binding-level resource knobs so opting-in from Python/JS cannot exceed caller time or memory caps.

Description

• Python: apply_sqlite_config now accepts timeout_seconds and max_memory, maps them to SqliteLimits::max_duration / max_db_bytes, and uses builder.sqlite_with_limits(...) instead of builder.sqlite(); constructor and reset call sites updated to pass the host limits.
• JavaScript: added derive_sqlite_limits(state) which maps timeout_ms and max_memory (MiB) into SqliteLimits, and switched the JS opt-in to builder.sqlite_with_limits(derive_sqlite_limits(state)).
• Kept the explicit env gate behavior unchanged (BASHKIT_ALLOW_INPROCESS_SQLITE=1) and preserved existing deny-list defaults; changes restrict sqlite runtime budgets to host-specified limits.

Testing

• Ran cargo fmt --all which completed successfully.
• Ran cargo check -p bashkit-python -p bashkit-js which completed successfully.

---

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	d5bec39	Commit Preview URL	May 08 2026, 09:10 AM