opencode's sessions read from its database; only what changed is re-read

opencode's sessions, read from where they are

The sidebar used to get opencode's session list by running opencode session list. That boots a whole Bun runtime for a few hundred bytes of JSON — and
the CLI only answers for the folder it is run in, which was the daemon's own.
So the sidebar saw one opencode session out of fifty-four, and paid three
seconds of CPU for it.

The daemon now reads opencode's database directly: read-only, in a few
milliseconds, never in the way of opencode itself. Every session, in every
project, is there. A new one shows up within a second or two — the database
folder is watched, and its write-ahead log is part of what is watched, since
that is where a fresh session sits for hours before it is folded in.

The CLI is kept as a fallback, for a database whose shape is not the one
expected — an opencode update that moves a column — and for the Linux build,
which is made without SQLite (see below).

Only what changed is read again

Claude writes to its session file on every message, and each write used to
send the daemon back over every session file on the machine. Now the file
watcher names what moved, and only that is read again; the full walk is kept
for the once-a-minute sweep, a settings change, and a watcher that lost track.

For those building from source

The sqlite cargo feature is on by default. The Linux binary published here
is built on Windows, where there is no C compiler for musl, so it is made with
--no-default-features and asks the CLI as before. A Linux build made on
Linux keeps the default.

No frontend change: sessionhub-web-1.2.38 from v0.0.38 is current.