Challenge 1: Downscaled Export With No Zoom Applied -- Solution
Walkthrough

Exporting a 2880x1800 native recording at 1920x1080 with no zoom
scales every character down to roughly two-thirds of its native size
before video compression even starts -- and compression algorithms,
tuned for natural imagery rather than sharp text edges, discard
exactly the kind of fine detail that distinguishes similar-looking
characters (a colon from a semicolon, a lowercase l from the digit
1). With no zoom applied to bring the relevant code panel closer to
its actual native size, that downscaling and compression loss lands
on the entire IDE at once, including panels the viewer doesn't
actually need to read closely -- there's no compensating factor
anywhere in the pipeline.

Increasing the editor's own font size AFTER recording doesn't fix
this, because the damage already happened during recording and
export -- the font size was baked into the pixels at the moment of
capture and downscaling. A larger font applied afterward to the
already-recorded, already-compressed video file doesn't add back
detail that compression already discarded; it can only make an
already-blurry area of the video larger, not sharper. The chapter's
own fix -- increasing font size BEFORE recording, so more native
pixels are dedicated to each character from the start -- has to
happen at the point of capture, not afterward, since resolution and
legibility lost during recording and export can't be recovered in
post.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader understands legibility loss
here happens at capture/export time (scaling + compression), not as
a property of the finished video file that could be adjusted
afterward -- correctly ruling out "increase font size after
recording" as a fix, since by then the relevant pixel detail is
already gone.