feat: dedicated goal DB

[jif-oai]

Why

Thread goals are moving toward extension-owned runtime behavior, but their persisted state was still stored in the shared state database. This makes the goal store harder to isolate and keeps future storage splits tied to ad hoc runtime plumbing.

This PR gives goals their own SQLite database while keeping the existing StateRuntime entry point. The goal is to make this the pattern for adding more dedicated runtime databases later.

This also reduce load on existing DB and reduce contention

Limitation

Thread preview from goal is not supported anymore. I'm looking into this
[EDIT]: solved

What changed

• Added a dedicated goals_1.sqlite database with its own goals_migrations directory.
• Moved thread_goals creation into the goals DB migration set.
• Dropped the old thread_goals table from the main state DB with a normal state migration. There is intentionally no backfill for existing goal rows.
• Changed GoalStore to be backed only by the goals DB pool.
• Removed the old goal-write side effect that filled empty threads.preview values from the goal objective.
• Added shared runtime DB path metadata so startup, telemetry, codex doctor, and repair handling can include future DBs without bespoke path lists.
• Updated Bazel compile data so the new goals migration directory is available to sqlx::migrate!.

Verification

• cargo check --tests -p codex-state -p codex-cli -p codex-core -p codex-app-server
• just fix -p codex-state
• just fix -p codex-cli
• just fix -p codex-app-server

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: fd1bdda453

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[etraut-openai]

Looks good. I manually built and ran locallly to ensure that there were no db migration issues.

I found a couple of small usability issues that would be good to fix:

init_state_db_for_app_server_target in the TUI should be updated. It currently attributes all db integrity failures to the state db, which will confuse uses if the problem is actually with the goal db.

Other comment inline related to doctor reporting.

[jif-oai]

Windows failure is unrelated and due to flake in the GH workers