SQLite fails fast with `SQLITE_BUSY` when another process holds the
database lock. This database, and others like it, are shared between Zed
instances. SQLite allows multiple readers at once, but only one writer
at a time. Writes are short-lived, but if multiple Zed instances try to
write to the file at the same time, the default fail-fast behavior
throws `SQLITE_BUSY` and the write is dropped instead of retried. The
fix is to keep trying the write for up to five seconds, so transient
lock contention resolves and the write succeeds instead of erroring.

A concrete case is the agent threads database (`threads.db`), which
lives in the shared per-user data directory and is not namespaced by
release channel. Running two Zed instances side by side means both can
attempt to write to the same file at the same time, resulting in the
error mentioned previously.

Release Notes:

- Fixed intermittent "database is locked" errors when sharing a database
across Zed instances