Exercise 3: Why Shared Cross-Screen Data Fits @Observable Better Than @State — Possible Solution
========================================================================================================

@State is designed around a single view OWNING one piece of real
data, with that data optionally passed down to that view's own
children via a Binding. Its whole real mechanism (per Exercise 1)
exists to let one specific view's own state survive across that
view's own struct recreations - it isn't designed around the idea of
several genuinely UNRELATED views, sitting in different branches of
the view tree, all needing to read and write the exact same underlying
data at once.

Connecting this to Chapter 4's value-type/reference-type distinction:
the underlying value @State manages is typically a plain value type
(an Int, a String, a Bool) - and per Chapter 4, assigning or passing a
value type creates a genuinely independent COPY. If two unrelated
views each somehow tried to hold their own separate @State copies of
"the same" data, those copies would immediately diverge the moment
either one changed its own copy - there would be no real, single
source of truth being shared, only two accidentally-similar-looking
but genuinely separate values.

An @Observable class is a real reference type (a class, not a
struct) - so passing it to two unrelated views doesn't copy it at
all; both views hold a reference to the exact same single underlying
instance, exactly like Chapter 4's own ShoppingCart example. A change
made through one reference is visible through every other reference to
that same real instance, which is precisely the "genuinely shared, one
source of truth" behavior needed for data used across several
unrelated parts of a screen - something a value-type-based @State
property was never designed to provide across independent views to
begin with.

ANSWER: @State is built around one view owning and persisting its own
value-type data, which per Chapter 4 gets copied (not shared) whenever
passed around - genuinely unsuited to keeping several unrelated views
in sync with one common source of truth. An @Observable class is a
reference type, so passing it to multiple unrelated views shares the
exact same single instance rather than copying it, exactly like
Chapter 4's ShoppingCart example - which is precisely the shared,
single-source-of-truth behavior cross-screen data actually needs.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly ties the @State-vs-@Observable design choice back to
Chapter 4's own value-type/reference-type distinction, explaining why
copying semantics make @State a poor fit for genuinely shared
cross-view data.