Exercise 1: Why res.send() Blocks a Later Logger — Possible Solution
====================================================================

WHAT res.send() ACTUALLY DOES
------------------------------
Per Express's own documented model (an application as "a series of
middleware function calls executed during the request-response
cycle"), res.send() ENDS the request-response cycle -- it writes the
real HTTP response and closes it out. Crucially, it does this WITHOUT
ever calling next().

MAPPING THIS ONTO CHAPTER 8'S OWN ONION MODEL
------------------------------------------------------------
Chapter 8's own build_chain() nests each middleware inside the next,
ending at a real handler in the center. A layer that returns a real
response without calling its own next parameter is, structurally, a
genuine short-circuit -- exactly what Chapter 8's own auth_middleware
did by returning "401 Unauthorized" directly instead of calling
next(request). Nothing registered AFTER a short-circuiting layer --
neither further middleware nor the real handler -- is ever invoked,
because the only thing that would have invoked them (a call to next())
never happened.

WHY THE ROUTE HANDLER ITSELF COUNTS AS "A LAYER" HERE
------------------------------------------------------------------
An Express route handler sits at the very center of the chain, in the
same position Chapter 8's own handler() occupies -- the innermost real
"and now produce the actual response" step. When it calls res.send(),
that's the innermost layer choosing to complete the cycle directly,
the same way Chapter 8's own crashing_handler or slow_handler produce
a real result. If app.use(myLogger) is registered AFTER this route,
myLogger sits OUTSIDE the route in registration order but never gets a
chance to run its own "before" code at all, because Express invokes
middleware strictly in registration order -- myLogger's own turn in
the chain never arrives, since the route already ended the cycle
before Express ever got to it.

THE KEY DISTINCTION FROM CHAPTER 8'S OWN NESTING
------------------------------------------------------------------
This is subtly different from Chapter 8's own build_chain(), where
registration order directly determines NESTING order (first-registered
= outermost). In the broken Express example, myLogger registered after
the route isn't "nested outside" the route at all -- it's simply never
reached, because Express processes registered handlers strictly in the
order they were added, and the route ahead of it already terminated
the cycle before myLogger's own turn came up.

WHY THIS WORKS AS AN ANSWER
----------------------------
It explains res.send()'s real behavior (ending the cycle without
calling next()) in Chapter 8's own already-established short-circuit
vocabulary rather than treating it as a new, unrelated concept, and
correctly identifies why registration order -- not nesting depth --
is what actually determines whether myLogger ever gets a turn at all.