feat(litestream): add configurable busy timeout

[Karavil]

Summary

Adds --litestream-busy-timeout option to configure SQLite's busy_timeout for litestream's database connection. Value is a duration string (e.g. "5s", "30s", "1m").

Default is "1s", which we believe is litestream's internal default (see litestream db.go NewDB - BusyTimeout: 1 * time.Second).

Motivation

We've been experiencing "database is locked" errors during heavy write operations. There's a comment in Zero's codebase that suggests this could cause deadlocks:

// packages/zero-cache/src/db/wal-checkpoint.test.ts (lines 83-85)
// With a BEGIN CONCURRENT, the checkpoint fails. Note that if this were
// litestream, this would result in a deadlock as litestream does not
// set a busy_timeout.

However, we found that litestream's source code shows a default BusyTimeout of 1 second. We'd appreciate clarification from the Zero team on whether this comment is still accurate or if something else is happening.

Change

• Adds busyTimeout config option (default "1s")
• Passes ZERO_LITESTREAM_BUSY_TIMEOUT env var to litestream
• Adds busy-timeout line to config.yml

Since we're setting the default to what we believe is litestream's internal default (1s), this should preserve existing behavior while allowing operators to tune it higher if needed.

Usage

# Increase busy timeout to 30 seconds
zero-cache --litestream-busy-timeout=30s

Questions for Zero Team

1. Is the comment in wal-checkpoint.test.ts still accurate? Does litestream actually not set a busy_timeout in Zero's setup?
2. If litestream's default is 1s, what explains the deadlock behavior we're seeing?
3. Is there a reason busy-timeout wasn't explicitly set in config.yml before?

[vercel]

@Karavil is attempting to deploy a commit to the Rocicorp Team on Vercel.

A member of the Team first needs to authorize it.

[darkgnotic]

Thank you @Karavil !

Can you please run npm run test -- -u to update the test snapshots?