Challenge 3: Explain Interceptor Ordering — Possible Solution
====================================================================

WHAT THIS MEANS FOR REJECTED CALLS: with auth registered BEFORE
logging, any call that fails the auth check gets rejected by the auth
interceptor and the chain short-circuits right there — the logging
interceptor, sitting after auth in the chain, NEVER RUNS for that
call. This means the team's logs will show every successful,
authenticated call, but will have NO RECORD AT ALL of unauthenticated
or rejected attempts — including potentially suspicious ones, like
repeated failed auth attempts that might indicate someone probing the
API or a misconfigured client.

THE REORDERING FIX: register the logging interceptor FIRST, before
the auth interceptor:

server.use(loggingInterceptor);
server.use(authInterceptor);

Now every call — successful or not — passes through the logging
interceptor first, before auth even runs, guaranteeing every attempt
gets logged regardless of whether it's later accepted or rejected by
auth. This is the exact same reasoning Express developers apply when
deciding whether a logging middleware should run before or after an
auth-checking middleware — placing observability first ensures nothing
gets silently missed by a later step in the chain short-circuiting.