Challenge 3: Justify the Interceptor Order — Possible Solution
====================================================================

Registering the logging interceptor BEFORE the auth interceptor means
EVERY call attempt to OrderService gets logged — including ones that
end up being rejected by the auth check for having a missing or
invalid bearer token.

Per Chapter 6's ordering gotcha: if auth were registered FIRST
instead, any call that fails authentication would be rejected right
there, and the chain would short-circuit before ever reaching the
logging interceptor — meaning failed/unauthenticated attempts against
OrderService would leave NO log record at all. For an order-creation
endpoint specifically, that's a real gap worth avoiding: repeated
failed auth attempts against CreateOrder could be a sign of someone
probing the API with invalid or stolen tokens, or a legitimate client
misconfigured with a stale token — either way, exactly the kind of
event worth having visibility into, not silently dropped from the
logs.

By logging first, this capstone guarantees a complete record of every
attempt against OrderService — successful order creations AND
rejected unauthorized attempts alike — which is the more useful
default for anything handling real user-facing actions like placing an
order.