Mobile: file tree cache fallback has no offline/stale indicator #44

Context

PR #14 (SwiftData-backed offline cache, issue #4) added a reposStaleReason /
prsStaleReason / issuesStaleReason / ticketsStaleReason pattern to AppStore so
every cached list can render OfflineBanner when it's serving cache-fallback data
instead of a fresh fetch. OfflineBanner's own doc comment states this is an issue #4
acceptance criterion: "cached content never looks indistinguishable from a fresh fetch."

AppStore.loadFileTree (mobile/Sources/HyperGitCore/Store/AppStore.swift) is the one
cached surface that doesn't follow this pattern — its catch path falls back to the
cache with no LoadState and no stale reason, and FileTreeView renders
store.fileTree with no OfflineBanner.

This is a real regression risk introduced by this same PR: previously the silent
fallback was session-scoped (MemoryCacheStore), so a stale tree could only be shown
until the app restarted. Now trees are persisted by SwiftDataCacheStore across
restarts, so a stale file tree can be presented as indistinguishable from fresh
indefinitely.

Caught independently by two review-cli reviewers (kimi-code/k3 and Claude Opus) during
PR #14's review.

Acceptance criteria

• AppStore gets a fileTreeStaleReason: String?, set/cleared in loadFileTree
  mirroring the other four loaders (repos/prs/issues/tickets).
• FileTreeView renders OfflineBanner when fileTreeStaleReason is non-nil,
  matching the pattern in ReposView/PullRequestsView/IssuesView/TicketsView.
• A test covers the loadFileTree cache-fallback path (currently untested —
  SwiftDataCacheStoreTests covers repo/ticket fallback through AppStore but
  nothing exercises loadFileTree's catch path).

User impact if not fixed

A user browsing a repo's file tree offline (or after a failed fetch) sees a tree that
looks identical to a live one, with no indication it may be stale — silently
contradicting the offline-indicator guarantee the rest of the app now provides.