fix(core): surface schema errors from a database migrated by a newer version

[H3XDaemon]

Issue for this PR

Closes #35986

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

When two installs of different versions share the default opencode.db (in my case a desktop build from June 5 and a bun-installed CLI on 1.17.18), the newer one migrates the schema and the older one keeps running its old SQL against it. Nothing fails at startup — it dies later inside prompt_async with the opaque defect below, which looks exactly like db corruption. I deleted my db over this before working out what happened; the reporter of #35986 went down the same road (VACUUM, pruning sessions, finally a fresh db).

{"code":"ERR_SQLITE_ERROR","errcode":1,"errstr":"SQL logic error"}

Two things make the failure this opaque, and this PR fixes both:

1. In sqlite.bun.ts / sqlite.node.ts the prepare call sits outside the try block, so prepare-time errors (no such column: agent — exactly what a schema mismatch produces) escape as raw defects instead of typed SqlErrors. Moved prepare inside the try.
2. The desktop build's logger at the time serialized the defect to JSON, and Error.message is non-enumerable, so the log kept only {code, errcode, errstr} (current builds print the message since refactor(core): replace legacy logger with Effect logging #31310). Even with the message visible, "no such column: agent" doesn't tell the user what happened or what to do. Now, when a statement fails with SQLITE_ERROR and the migration table contains ids newer than this build knows, the SqlError message says so: database was migrated by a newer version of opencode (…); update this installation.

DatabaseMigration.apply() also logs a warning at startup when it sees migrations from a newer build. It deliberately does not refuse to start: most migrations are additive (this db has 38, and the breakage came from a single one dropping three columns), so a mixed-version setup usually still works and blocking it would trade one failure for another.

How did you verify your code works?

New test drives the real client (core's sqlite.bun layer): db at head + a future migration id + a query against a missing column now yields a typed SqlError (previously a defect) whose message names the future migration. Full database-migration.test.ts passes (18/18), bun typecheck clean. The original failure is reproducible on my machine by restoring a newer-schema db against the old desktop build; the error text this PR produces is exactly what that situation needed.

Screenshots / recordings

n/a

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.