Exercise 3: Why "The Server Happened to Agree With the Web Client" Isn't the Real Fix — Possible Solution
====================================================================

WHAT ACTUALLY HAPPENED IN THIS CHAPTER'S OWN EXAMPLE
------------------------------
server_calculate_total() does subtract the $5 fee before applying the
loyalty discount - the same order web_client_calculate_total() used -
so it's true that, coincidentally, the server's own result (103.5)
matched the web client's own thick-client result rather than the
mobile client's (103.0). It would be easy to read this as "the fix
worked because the server happened to pick the same order the web team
already used."

WHY THAT'S NOT THE ACTUAL REASON THE DISCREPANCY IS FIXED
------------------------------
The bug this chapter verified wasn't "the web client is right and the
mobile client is wrong" - it was that TWO INDEPENDENT IMPLEMENTATIONS
of the same rule could silently disagree with EACH OTHER, with nothing
in the system able to detect or prevent that. If the server's own
get_total() had instead matched the mobile client's ordering (giving
103.0 instead of 103.5), the fix would have been EQUALLY effective -
both clients would still receive an identical, single, authoritative
number. The specific value the server returns is a business decision
someone has to make once; the ARCHITECTURAL fix is that only one
implementation exists to make that decision at all.

THE REAL REASON, STATED DIRECTLY
------------------------------
Before the fix, "what's the correct total for this order" had two
different, independently-computed answers, and no way to know which
one (if either) was actually intended. After the fix, verified
directly - both mobile_client_via_api() and web_client_via_api()
returned the identical 103.5 - there is exactly ONE answer, because
there is exactly one place (server_calculate_total()) where the
calculation happens at all. The discrepancy is eliminated not because
the server chose the "right" ordering, but because there is no longer
a second implementation left to disagree with it.

WHAT WOULD STILL BE TRUE IF THE SERVER HAD CHOSEN THE OTHER ORDER
------------------------------
Had server_calculate_total() matched the mobile client's own ordering
instead, both mobile_client_via_api() and web_client_via_api() would
have returned 103.0 instead of 103.5 - still identical to each other,
still a fully resolved discrepancy. The specific correct business
answer is a decision to be made (and, per Chapter 9, recorded in an
ADR) separately from the architectural fact that centralizing the
logic is what guarantees agreement, regardless of which specific
ordering gets chosen.

WHY THIS WORKS AS AN ANSWER
------------------------------
The explanation directly distinguishes "which specific number is
correct" (a business decision, coincidental to which client happened
to match) from "why do both clients now agree" (an architectural
guarantee from having only one implementation), using this chapter's
own verified before/after numbers as evidence rather than treating the
match with the web client as the actual fix.