Challenge 3: panic! vs. Result, and the Risk of unwrap() — Possible Solution
====================================================================

WHEN panic! IS THE RIGHT CHOICE: for genuinely unrecoverable situations
— a broken program invariant that indicates a real bug, not an
expected condition. CONCRETE EXAMPLE: a function that's supposed to
receive an index that's already been validated as in-bounds elsewhere
in the code, but somehow receives an out-of-bounds one anyway — that
represents a logic error in the program itself, not something the
caller could reasonably be expected to "handle" at runtime. Panicking
immediately, loudly, at the exact point the invariant was violated, is
more useful than trying to limp along with corrupted assumptions.

WHEN Result IS THE RIGHT CHOICE: for expected, recoverable failure
conditions that are a normal part of the program's operation.
CONCRETE EXAMPLE: this chapter's own parse_age function — a user
typing an invalid age into a form is an entirely expected, routine
occurrence, not a bug in the program. Returning Result lets the
caller decide how to respond (show an error message, ask the user to
retry) rather than crashing the whole program over ordinary bad input.

WHAT'S RISKY ABOUT .unwrap() ON PARSED USER INPUT: user-provided input
is, by definition, NOT guaranteed to be valid — a user can type
anything at all. Calling .unwrap() on the Result from parsing that
input converts every single instance of genuinely expected, normal bad
input (a typo, an empty field, non-numeric characters) into a full
PROGRAM CRASH via panic, rather than a graceful, handled error message.
This is exactly the mistake this chapter's closing warn-box described:
treating something that WILL realistically fail in production as if it
were structurally guaranteed to succeed.