Revert "Revert "Remove Startup Loading Delays and Improve Cache-First Offline Operation""

[marcellogalhardo]

Revert of #1831. Restores the cache-first code to continue the review and discussion from the original pull request (#1805) and the Slack thread.

Original Description

Conference attendees often encounter congested venue networks with poor connectivity. When opening the app between presentations, users need to see the schedule immediately without waiting for network responses.

Previously, CacheFirst treated cached queries as stale and blocked screen transitions until a network request completed on launch. This caused multi-second startup delays and loading errors when offline.

This change updates CacheFirstInterceptor to emit cached data from local storage immediately with zero delay, then trigger a background network sync asynchronously.

As a result, screens render instantly using cached data, while background requests update local storage silently and ignore network failures when offline.

Rationale for Immediate Cache Rendering

• Schedule updates happen, but are infrequent enough during an event that a user tapping a moving item in that sub-second refresh window is very unlikely.
• When updates do happen, Compose stable keys (key = { it.id }) minimize visible flicker by diffing items in place rather than doing a full redraw.
• Conference Wi-Fi often shows full signal, but actual throughput is dead. A connectivity check would incorrectly report online, leaving the user blocked on a loading spinner while moving between rooms.

Because of this, my intuition is that immediate cache rendering offers a significantly better UX during a live conference environment.