Exercise 3: Why a Real Hang Is Directly Connected to @MainActor — Possible Solution
========================================================================================

A "hang," as the Hangs instrument defines and measures it, is a real,
specific stretch of time during which the main thread was genuinely
blocked long enough that the app stopped responding to touch - the
screen freezes, a tap does nothing, and the user has no way of knowing
whether the app is still actually working or has crashed outright.

Architecture & Data's own @MainActor chapter established the real
underlying rule this connects to directly: SwiftUI's entire UI updates
on the main thread, and @MainActor is the real, compiler-enforced
mechanism that keeps UI-touching code running there. But that same
chapter's own real warning was that @MainActor guarantees WHERE code
runs, not how fast it runs - it says nothing at all about how long a
given piece of @MainActor code is allowed to take before returning
control back to the UI.

A concrete example makes the connection direct: imagine a real
@MainActor method that, instead of properly awaiting an async network
call the way syncWithServer() does, synchronously decodes a very
large, real JSON response directly on the main thread - say, parsing
thousands of tasks from a full backup file in one single, uninterrupted
loop. Nothing about @MainActor prevents this from compiling and
running correctly. But for the real, measured duration of that decode
- however many milliseconds or seconds it genuinely takes - the main
thread is completely occupied and cannot process a single touch event,
producing exactly the frozen, unresponsive symptom the Hangs instrument
is built to detect and flag.

ANSWER: A hang is the real, user-visible symptom of genuinely heavy
synchronous work running on the main thread - and because @MainActor
only guarantees that UI-touching code runs on the main thread, not that
it runs quickly, a real @MainActor method that does expensive
synchronous work (like decoding a very large JSON payload directly,
instead of properly awaiting it) will freeze the UI for exactly as long
as that work takes, which the Hangs instrument then measures and flags.

WHY THIS WORKS AS AN ANSWER
------------------------------
This gives a concrete, plausible example of real @MainActor code that
would cause a hang, explaining specifically why @MainActor's own
guarantee (correct thread) doesn't protect against the Hangs
instrument's own concern (blocking duration).