fix: scope tasks cache invalidation per source and persist it to SQLite

[HrushikeshAnandSarangi]

What changed

Refresh no longer wipes both sources' caches — invalidation is scoped to the active source (gh: / linear: prefixes). The in-process cache is now backed by SQLite (~/.tempest/tasks-cache.db), so lists/threads survive restarts via a stale-while-revalidate pattern, with rows tagged by account so switching accounts can't serve cross-account data.

The store intentionally lives in its own SQLite file rather than inside the dbiso crate's DB — it reuses dbiso's established pattern (per-op connection, schema-on-open, ~/.tempest/<name>.db) instead of importing the crate, because the cache is disposable data with its own eviction lifecycle (7-day age sweep, 500-row cap) and shouldn't be coupled to a feature database.

Also fixes parse_gh_user for newer gh auth status output, prunes orphaned frontend cache entries, and rebases onto the pagination rewrite.

For reviewers: the cache ladder is in cached_json() (src-tauri/src/tasks.rs); the TS/Rust cache-key formats in useTasks.ts must match exactly or hot-swap silently stops working.

Related issue

Closes #47

How was this tested

• cargo test --lib: 22 passed, including new regression tests — parse_gh_user_handles_both_auth_status_formats, scoped prefix invalidation, and the tasks_store suite (delete_prefix_is_exact_and_scoped, fresh_get_respects_owner_and_age, corrupt-payload handling, owner-hash determinism)
• Upstream's two cache tests were made hermetic as part of this: they previously called tasks_cache_invalidate, which now also evicts the developer's real on-disk SQLite mirror during cargo test
• npx tsc --noEmit: clean
• Manual on Windows: verified ~/.tempest/tasks-cache.db is created and repopulated after invalidation, refresh on one source leaves the other source's rows intact, and rows carry the expected owner tags

Checklist

• npx tsc --noEmit passes
• cargo check passes (if backend changed)
• I've tested this on my OS — noted which:
• Docs updated if user-facing behaviour changed
• No secrets, tokens, or personal paths in the diff

[vercel]

@HrushikeshAnandSarangi is attempting to deploy a commit to the Harsha's projects Team on Vercel.

A member of the Team first needs to authorize it.

[gsvprharsha]

Everything works perfectly. Safe to merge