Preserve the local cache across startup and sync failures

[rsheyd]

Summary

• retain the SQLite cache between normal application runs
• load cached projects and tasks immediately while the initial Todoist sync runs
• keep cached data visible when startup sync or cache refresh fails
• reuse the persisted Todoist backend record instead of creating a duplicate on every launch
• replace successful remote snapshots atomically so remotely removed objects do not linger

Why

Terminalist currently deletes its cache during ordinary startup. That makes startup depend on a successful Todoist request, leaves the UI without useful data when the network is unavailable, and can invalidate a database file that another running process still has open.

The cache is now durable. Remote data is fetched before beginning a database transaction, and the backend-specific snapshot is replaced within that transaction. A failed write rolls back to the last usable cache; a failed remote sync leaves the cached view intact.

User impact

Users see their cached task data immediately at startup and can still inspect it if Todoist is temporarily unavailable. Successful syncs continue to refresh the cache authoritatively.

Validation

• cargo fmt --all -- --check
• cargo test (59 unit/integration tests and 2 doc tests passed)
• regression coverage for database reuse, offline startup, transactional rollback, and removal of objects absent from a successful snapshot

[romaintb]

@rsheyd I actively tried not to retain the SQLite file between sessions because suddenly we have to handle database schema revisions, schema migrations, and so on.
I understand the use case here and the value for users, but this introduces a lot of complexity, hence my initial decision to start fresh every time.

But I guess we could store the DB's schema version (number) somewhere and re-create it only when that version changes? That would be treating the DB as a cache, invalidating it and recreating its structure only when needed. 🤔 That would probably be the best of both worlds.
(If we decide to go that way, I can merge this PR and work on that in tree)

WDYT ?

[rsheyd]

@romaintb Yeah, I think that makes sense. I thought more about the schema migration implications and agree with you.

Treating it explicitly as a cache and invalidating/recreating it when the schema version changes seems like a cleaner approach than maintaining migrations for cached data.

I've been doing some lightweight migrations in https://github.com/rsheyd/terminalist-edge, but thinking about it more, I don't think there's much reason for that complexity as long as Todoist remains the authoritative source of data. There is currently a local Trash feature in edge that retains deleted tasks, but I'm reconsidering that as well — it may make more sense to implement soft deletion remotely (e.g. via a Terminalist Trash project) so the local DB can remain entirely disposable.

So 👍 from me on your suggested approach. If you're happy to merge this PR as-is and add the schema-version/cache invalidation afterward in tree, that sounds good to me.