Cache Home status across navigation

[h3nock]

What changed and why

Keep Home status and connector metrics in a long-lived store so returning to Home renders cached values immediately instead of repeating connector, Apple Notes, file, export, and knowledge-count discovery. Refreshes remain stale-aware, imports refresh the affected knowledge counts, and session resets clear cached account state.

Product invariants affected

none

How it was verified

• Exercised the Home navigation flow in the named omi-home-status-cache desktop bundle and confirmed cached status remains available when leaving and returning to Home.
• xcrun swift build -c debug --package-path Desktop --scratch-path /tmp/omi-home-status-cache-swift-build completed successfully on the latest upstream/main.
• The repository-wide suite still has the previously identified unrelated API routing assertion and Firebase test-initialization crash; neither failure is in code touched by this PR.

Tests

• xcrun swift test --package-path Desktop --scratch-path /tmp/omi-home-status-cache-swift-build --filter HomeStatusStoreTests passed 6/6 tests.
• Coverage includes stale-cache throttling, shared concurrent refreshes, import-driven count refreshes, stale-response protection, persisted device history, and manual-import refreshes.

Scoped cleanups (optional)

none

[Git-on-my-level]

Thanks for the careful work here. This looks like a cohesive desktop performance/privacy improvement: moving Home status into a long-lived store should make returning to Home feel much faster, and I like that the PR adds account-scoped persistence plus focused tests for stale-cache throttling, concurrent refresh coalescing, import-triggered count refreshes, stale-response protection, and account switching.

I’m not seeing a concrete blocker in the diff from static review, and the relevant desktop Swift build/tests/checks are green. I’m leaving this as a positive maintainer signal rather than a formal approval because the change touches account-scoped cached status for connector metrics, memory-import state, export status, and Omi-device history. That is a user-data/privacy-sensitive surface, so a human maintainer should sanity-check the intended account-boundary behavior before merge.

Specific things I’d want the maintainer to confirm:

• The legacy UserDefaults migration behavior is acceptable when existing unscoped connector/device-history keys are first associated with the currently signed-in user.
• No Home status or connector metrics can be written or restored under the wrong signed-in account during sign-in/sign-out or no-user startup states.
• The new shared HomeStatusStore lifecycle in ViewModelContainer is the intended owner for both Dashboard and Apps connector status.

Overall: promising and well-tested, but needs human maintainer review because it changes cached per-account status behavior.