Exercise 3: Why the Two Verified Findings Are the Same Finding — Possible Solution
====================================================================

WHY PricingEngine CAN'T "CHOOSE" TO USE A REAL ADAPTER IN A TEST
------------------------------
This chapter verified PricingEngine's own source contains zero
reference to RealInventoryAdapter, RealNotificationAdapter, or any
other concrete adapter class - it only ever calls
self.inventory.get_stock_level(...) and
self.notifications.notify_low_stock(...), methods defined on the
abstract InventoryPort/NotificationPort. PricingEngine has no way to
"reach past" whatever object it was constructed with to specifically
demand a real, slow implementation - it genuinely cannot tell the
difference between a fake and a real adapter from the inside, because
both satisfy the identical port interface.

WHY THIS IS EXACTLY WHAT MAKES SWAPPING IN A FAKE SAFE
------------------------------
Because PricingEngine's own behavior is defined entirely in terms of
what the ports promise to return, not in terms of which concrete class
is providing that return value, a test can construct
PricingEngine(FakeInventoryAdapter(...), FakeNotificationAdapter(...))
with total confidence that PricingEngine.calculate_price() will run
its real, unmodified business logic - the same logic that would run
in production - just against data supplied instantly instead of after
a simulated 10ms delay. This chapter's own first finding (identical
price, 114.99999999999999, from both fake and real adapters) is DIRECT
PROOF of this: if PricingEngine somehow depended on which adapter it
was talking to, fake and real would have produced different results.
They didn't, because PricingEngine's logic literally cannot see which
one it has.

CONNECTING BOTH FINDINGS DIRECTLY
------------------------------
The ~18,111x speedup isn't a separate, lucky consequence of using
fakes - it's the direct, structural payoff of PricingEngine's own
inability to reference a concrete adapter. If PricingEngine had ever
imported RealInventoryAdapter directly (even just to type-check
against it, or to fall back to it in some edge case), a test
constructing a fake would risk running through code paths that
secretly still depended on the real class being available or behaving
a certain way - and the fake wouldn't be a genuine stand-in anymore.
Because the reference is verified to be zero, the fake is provably a
complete, safe substitute, and every millisecond of the real adapter's
own artificial delay is avoided entirely, with nothing lost.

WHY THIS WORKS AS AN ANSWER
------------------------------
The explanation traces a direct causal chain from this chapter's own
verified zero-reference finding to its own verified speedup finding,
rather than treating them as two separate coincidental results, and it
explains concretely what could go wrong (a hidden dependency on a real
class) if the zero-reference property didn't hold.