Exercise 3: Why Automatic Task Cancellation Is a Genuine Safety Guarantee — Possible Solution
=====================================================================================================

Per Chapter 6, a @State property's own real underlying value is stored
externally by SwiftUI, keyed to a specific view's own identity within
the view tree - not inside the disposable struct instance itself. That
external storage is what lets a view's state survive across repeated
struct recreations. But that same storage is also tied to the view's
own real PRESENCE in the tree - once a view is genuinely removed (the
user navigates away, for instance), SwiftUI eventually cleans up the
storage associated with that view's own identity, since nothing valid
remains to own or display it any longer.

Without automatic cancellation, a .task {} closure that had already
started a real, in-flight network request before the view disappeared
would simply keep running in the background, completely unaware the
view is gone. When that request eventually finished, its own closure
would try to write into a @State property (like `quote = try await
fetchQuote()`) belonging to a view that no longer meaningfully exists
in the tree - at best, a genuinely wasted network request and CPU
work for a result nobody will ever see; at worst, a real crash or
undefined behavior from writing into state whose own backing storage
may already be in the process of being torn down.

SwiftUI's real, automatic cancellation specifically prevents this: the
moment the view genuinely disappears, the async Task backing that
.task {} closure is cancelled, and any subsequent await point inside
it (including the network call itself, if URLSession honors the
cancellation, which it real does) can throw a real cancellation error
instead of continuing to run to completion and writing into now-invalid
state.

ANSWER: Because @State stores its real value externally, keyed to a
specific view's own identity, that storage becomes invalid once the
view genuinely disappears from the tree. Without automatic
cancellation, a still-running .task {} closure could try to write into
that now-invalid storage once its network request eventually finished
- wasted work at best, undefined behavior or a crash at worst.
Automatic cancellation prevents this by stopping the async work the
moment the view disappears, rather than letting it run to completion
against state that no longer meaningfully exists.

WHY THIS WORKS AS AN ANSWER
------------------------------
This connects .task's own automatic cancellation directly to Chapter
6's externalized-@State-storage mechanism, explaining the concrete
real failure mode (writing into invalid state) that cancellation
exists specifically to prevent.