feat: proactive feed refresh engine

[SebastianBoehler]

Issue Spec: Proactive Feed Refresh Engine

Summary

Build the technical layer that keeps the proactive home feed up to date without adding latency when the user opens the app. The home screen should render a cached HomeFeedSnapshot immediately, while refresh work happens in the background or asynchronously after first paint.

Goal

Provide an up-to-date enough proactive feed while respecting mobile background execution limits, battery constraints, privacy, and startup performance.

Scope

• Define a local HomeFeedSnapshot cache model with generatedAt, sourceFreshness, and stale/offline metadata.
• Implement foreground refresh after app open when the cached snapshot is stale.
• Implement best-effort periodic background refresh:
  • Android: WorkManager periodic work, with 15 minutes as the platform minimum interval.
  • iOS: BGAppRefreshTask or equivalent best-effort background refresh, without assuming exact timing.
• Refresh cheap deterministic data first: schedule, deadlines, Mensa, route hints, and notification-worthy changes.
• Recompute the feed using deterministic ranking/templates.
• Treat LLM/generative summarization as optional, asynchronous, and never required for app startup.

Out Of Scope

• Guaranteed cron-like execution on iOS.
• Always-on passive listening.
• Running expensive model inference every 15 minutes by default.
• Hosted credential routing or hosted storage of sensitive student data.
• Blocking the home screen until all sources are refreshed.

Acceptance Criteria

• App entry can render the last cached HomeFeedSnapshot immediately.
• If the snapshot is stale, refresh starts asynchronously and updates the UI when complete.
• Snapshot metadata exposes lastUpdated, freshness per source, and offline/stale state.
• Android background refresh uses a platform-appropriate scheduled worker with configurable interval and constraints.
• iOS background refresh is implemented or documented as best-effort, with no guarantee of exact 15/30 minute execution.
• The feed has deterministic fallback generation that does not require an LLM.
• Expensive assistant/LLM generation can be skipped, delayed, or restricted to favorable conditions such as foreground, charging, WiFi, or manual refresh.
• Failures from one source do not prevent rendering other available feed items.

Gates To Pass

• Latency gate: first home feed render does not wait for network calls, background workers, or LLM inference.
• Freshness gate: stale data is visible to the user and distinguishable from fresh data.
• Platform gate: Android and iOS scheduling behavior is documented separately.
• Battery gate: background refresh uses constraints and does not continuously poll.
• Privacy gate: refresh jobs operate on local credentials/data and do not route student credentials through hosted services.
• Reliability gate: partial source failures produce explicit degraded states rather than fake data.
• Test gate: tests or documented checks cover fresh cache, stale cache, offline state, partial source failure, and refresh success.
• Demo gate: a reviewer can open the app, see cached content immediately, trigger/observe refresh, and inspect lastUpdated.

Suggested Branch

feat/proactive-feed-refresh-engine