Exercise 3: Why .font(.body) vs. .font(.system(size: 17)) Determines Real Dynamic Type Support — Possible Solution
==========================================================================================================================

.font(.body) references one of SwiftUI's own real, built-in TEXT
STYLES - a named, semantic category (like .body, .headline,
.largeTitle) that the system itself defines as a real, specific point
size FOR THE USER'S CURRENT Dynamic Type setting, not a fixed value
baked permanently into the app. When a user increases their own real
system text size in Settings, every real view using .font(.body)
throughout the app automatically re-renders using the new, larger real
point size that setting now maps .body to - with zero extra code
required, exactly as the chapter's own finding-box described.

.font(.system(size: 17)) is a genuinely different, structurally
different kind of value - a literal, real, fixed point size specified
directly by the developer, with no real connection to the user's own
Dynamic Type setting at all. At the specific moment a real device
happens to be using its own smallest, default text-size setting,
.font(.system(size: 17)) might coincidentally render at roughly the
same size .body currently does - which is exactly why the two can look
identical at first, misleadingly suggesting they're interchangeable.
But increasing Dynamic Type afterward reveals the real, structural
difference: .body scales up correctly along with every other real
built-in text style, while .font(.system(size: 17)) stays frozen at
exactly 17 points regardless of what the user's own accessibility
settings actually specify.

ANSWER: .font(.body) references a real, named text style whose actual
point size the system itself determines based on the user's current
Dynamic Type setting, so it scales automatically when that setting
changes. .font(.system(size: 17)) is a fixed, literal point size with
no connection to Dynamic Type at all - the two can look identical at
the smallest default text size, which is exactly why the difference
only becomes visible once a user actually increases their own real
system text size, at which point only the .body version continues to
scale correctly.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real structural difference (a semantic, user-setting-
aware style vs. a fixed literal value) that determines Dynamic Type
support, rather than treating the two as merely different-looking
syntax for the same underlying thing.