Challenge 3: Why 'static Isn't a Real Fix — Possible Solution
====================================================================

Changing a function's declared return type from &'a str to &'static
str doesn't change what data the function ACTUALLY returns — it only
changes what the compiler is being TOLD to assume about that data's
lifetime. If the function's real logic returns a reference to data
that does NOT actually live for the entire program (say, a reference
into a String that was created locally inside the function, or passed
in with a genuinely shorter lifetime), declaring the return type as
&'static str doesn't magically extend that data's real lifetime to
match — it just makes a FALSE PROMISE to the compiler.

WHAT ACTUALLY GOES WRONG: in practice, the Rust compiler generally
won't even let this compile in the first place if the actual
underlying data isn't genuinely 'static — trying to return a reference
to, say, a local String created inside the function as &'static str
still fails to compile, now with a DIFFERENT, often more confusing
error (something like "cannot return value referencing local
variable"), because the compiler checks that the ACTUAL data satisfies
whatever lifetime is claimed, not just that the annotation was written
down. So "changing it to 'static to silence the error" typically just
trades one compile error for a different, harder-to-relate-back-to-the-
real-problem compile error, rather than fixing anything.

In the rarer case where it DOES compile (e.g., the underlying data
genuinely was a string literal or something else already 'static), the
fix accidentally "worked" only because the real data happened to
qualify — but this teaches the wrong lesson and papers over what should
have been a deliberate design decision (e.g., "this function should
only ever be given 'static input") rather than a lifetime annotation
chosen purely to make an error message go away. This is exactly why
this chapter's warn-box frames a stray 'static requirement as a signal
that the REAL fix likely belongs somewhere else — in how ownership or
borrowing is structured in the surrounding code, not in the
annotation itself.