Challenge 3: Fix the return Context Bug — Possible Solution
====================================================================

Given a subroutine ending with:
    return @results;

Rewritten to always return the count, regardless of calling context:
    return scalar(@results);

One-sentence explanation of why the original wouldn't reliably work:
return is itself context-sensitive (per this chapter's own warn-box),
so return @results; propagates whatever context the SUBROUTINE was
called in down into @results — meaning it returns the full list when
called in list context, but only the element count when called in
scalar context, and a caller who specifically wants "always the
count" cannot rely on that behavior being consistent across every
call site.

WHY THIS WORKS AS AN ANSWER
------------------------------
scalar(@results) reuses the chapter's own explicit context-forcing
tool directly — wrapping @results in scalar(...) guarantees it's
always evaluated in scalar context (the element count), completely
independent of whatever context the calling code itself happens to
use. Whether the caller writes my @x = the_sub(); or my $x =
the_sub();, this version's return value is the count either way.

The explanation reuses the chapter's own warn-box almost word for
word — "return @array; Isn't Always 'Return the Array'" — because
that warn-box's exact scenario (a plain return @array; unexpectedly
returning a count instead of the array, when called from scalar
context) is precisely the bug this challenge asks to identify and
fix, just phrased from the opposite direction: here, a caller WANTS
the count reliably, and the original return @results; only gives that
by accident when called in scalar context, not by design.