Challenge 2: Explain Deadline Propagation — Possible Solution
====================================================================

WITHOUT PROPAGATION (independent timeouts at each hop): suppose
Service A sets its own 5-second timeout waiting for B, B sets its own
5-second timeout waiting for C, and C sets its own 5-second timeout
for whatever it does internally. If C takes 4.9 seconds to respond, B
receives C's response just under B's own 5-second timeout — but B
has ALREADY spent 4.9 of its 5 seconds waiting on C, leaving almost no
time to do its own remaining work before B's timeout to A fires. Each
hop's timeout is set in isolation, with no awareness of how much of
the OVERALL budget has already been consumed by earlier hops in the
chain.

WITH DEADLINE PROPAGATION: a single deadline (say, "5 seconds from
when A's original call started") is passed along with the call from A
to B to C. Each service in the chain can see exactly how much time
remains in the SHARED budget, not just its own local slice. If C is
running slow and the shared deadline is about to expire, C can be
cancelled immediately with DEADLINE_EXCEEDED rather than B waiting out
its own independent timeout only to then not have enough real time
left to do anything useful with C's (late) response.

WHAT THIS BUYS THE CHAIN: propagation turns three independently-guessed
timeout budgets into ONE globally coherent deadline that every hop
respects — preventing the specific failure mode where each hop's
timeout looks reasonable in isolation, but stacking them (or having
each hop reset its own clock) means the true end-to-end wait A
experiences can be far longer than any single hop's timeout would
suggest, and resources across the whole chain aren't held waiting on
work that's already doomed to exceed the real deadline.