Challenge 2: Fix an ANR-Prone Function — Solution

// The problematic version
suspend fun loadUserProfile(): UserProfile {
    return readFromDiskBlocking()   // BUG: a blocking call inside a suspend
                                     // function doesn't automatically become
                                     // non-blocking — it still blocks whatever
                                     // thread this suspend function happens
                                     // to be running on.
}

// The fixed version
suspend fun loadUserProfile(): UserProfile = withContext(Dispatchers.IO) {
    readFromDiskBlocking()
}

Notes:
- Simply marking loadUserProfile() as "suspend" does NOT make
  readFromDiskBlocking() itself non-blocking — this repeats Course 2
  Chapter 6's warning box directly: suspend only means a function CAN
  pause without blocking; it doesn't automatically move blocking work
  off whichever thread is currently running it.
- Dispatchers.IO is the correct choice here (not Dispatchers.Default)
  because readFromDiskBlocking() is I/O-bound work — waiting on disk
  access — matching Course 2 Chapter 6's distinction between CPU-bound
  and I/O-bound dispatcher choices.
- If loadUserProfile() is called from viewModelScope.launch { } (the
  standard pattern from Course 2), the FIXED version genuinely never
  blocks the main thread — the blocking legacy call runs on
  Dispatchers.IO's dedicated thread pool instead, exactly avoiding the
  5-second-block ANR trigger described in the chapter, even though the
  underlying legacy function itself was never rewritten to be
  suspend-aware.