Challenge 1: Auto-Zoom Helps Legibility but Not Automatically Pacing
-- Solution Walkthrough

Auto-zoom is a direct win for legibility because it solves the exact
problem Chapter 2 identifies: code sitting in a corner of a large
monitor, or shown at a shrunk-down size, is genuinely hard to read
once compressed. By magnifying whatever area the cursor is actively
interacting with, Screen Studio puts more native pixels behind the
code a viewer actually needs to read, which directly counters the
scaling-and-compression problem regardless of anything else happening
in the video.

It isn't automatically a win for pacing because WHEN a zoom happens is
tied to mouse activity, not to how long a viewer actually needs to
read what's on screen. The zoom engine reacts to clicks and cursor
movement -- it has no way to know whether a given click was
significant (opening the file that matters for this step) or
incidental (dismissing a popup, clicking an unrelated tab). A rapid
sequence of clicks produces a rapid sequence of zoom changes
regardless of which of those clicks actually mattered to the viewer,
and per Chapter 2's own pacing criterion, that can rush past moments a
first-time viewer needed to actually read and absorb -- exactly the
"curse of knowledge" pacing problem the presenter is often the worst
judge of noticing themselves.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can separate what a feature
solves (spatial magnification, which is a legibility problem) from
what it doesn't control (timing relative to a viewer's actual reading
need, which is a pacing problem) -- recognizing that a single feature
can genuinely help one of Chapter 2's criteria while doing nothing
for, or even working against, another.