Avoid mixed SQLite access during TUI startup

[wesm]

Issue #401 exposed a TUI startup crash while msgvault sync was active: the process could rebuild the Parquet cache through DuckDB while also holding go-sqlite3 connections and starting background FTS maintenance. That repeats the same mixed-SQLite-library risk already documented for daemon cache rebuilds, where DuckDB's bundled SQLite should not attach the live database inside a process that also owns normal msgvault SQLite connections.

This changes interactive startup so the automatic cache build runs before the long-lived TUI store is opened, and FTS maintenance starts only after the query engine is initialized. The DuckDB-backed TUI engine also defaults to direct SQLite fallback for detail reads instead of attaching the live database through sqlite_scanner, preserving fast Parquet aggregates without keeping two SQLite implementations attached to the same WAL database in the interactive process.

The regression coverage locks in that TUI DuckDB options keep sqlite_scanner disabled by default. Standard Go formatting, vetting, and full tagged tests pass locally.

[roborev-ci]

roborev: Combined Review (c0d5292)

Medium issue found in the TUI startup/cache ordering; no security-impacting issues were reported.

Medium

• cmd/msgvault/cmd/tui.go:86 and cmd/msgvault/cmd/tui.go:123
  The new pre-open cache build runs before InitSchema / runStartupMigrations, while the old post-open build remains. On fresh or upgraded databases, the first build can fail on missing migrated columns or write cache state from pre-migration data. After migrations, the second block can either skip because staleness does not track participant-only migrations, leaving stale Parquet, or retry buildCache while s.DB() is open, reintroducing the mixed DuckDB/go-sqlite3 access this change is trying to avoid.
  Fix: Run schema/migrations first on a short-lived store, close it, build the cache once, then reopen for the TUI; alternatively use the existing subprocess cache build path. Remove the duplicate post-open cache build.

---

Panel: ci_default_security | Synthesis: codex, 9s | Members: codex_default (codex/default, done, 2m14s), codex_security (codex/security, done, 13s) | Total: 2m36s

[wesm]

Addressed the review finding in a28897d. TUI startup now opens a short-lived store to run InitSchema/startup migrations, closes it before any DuckDB cache export, performs at most one cache build, then reopens the migrated store for the interactive TUI.

The linked CI job failed while exporting Docker Buildx cache (error writing layer blob: not_found), not in Go validation. Local go fmt ./..., tagged go vet ./..., and make test all pass after this change.

[roborev-ci]

roborev: Combined Review (a28897d)

No issues found.

---

Panel: ci_default_security | Synthesis: codex | Members: codex_default (codex/default, done, 4m8s), codex_security (codex/security, done, 14s) | Total: 4m22s