Exercise 2: A Second Redeploy — Possible Solution
====================================================================

THE SEQUENCE
------------------------------
    registry.register('InventoryService', '10.0.0.5:8080')   # initial
    hardcoded_first_address = registry.discover('InventoryService')  # captured here, at startup

    registry.register('InventoryService', '10.0.0.9:8080')   # first redeploy
    registry.register('InventoryService', '10.0.0.14:8080')  # second redeploy

Only the latest address (10.0.0.14:8080) is treated as actually
listening.

RESULTS
------------------------------
    hardcoded client own captured (very first) address: 10.0.0.5:8080
    hardcoded client call succeeds: False
    discovery client looks up: 10.0.0.14:8080
    discovery client call succeeds: True

VERIFYING THE DISCOVERY CLIENT KEEPS WORKING ACROSS BOTH REDEPLOYS
------------------------------
The discovery client's own discover() call correctly returned the
address from the SECOND redeploy (10.0.0.14:8080), not the first
(10.0.0.9:8080) or the original (10.0.0.5:8080) - it always reflects
whatever the registry's own most recent register() call set, regardless
of how many redeploys happened in between. This confirms discovery
doesn't just survive one redeploy - it survives an arbitrary number of
them, since it never caches anything itself.

VERIFYING THE HARDCODED CLIENT STAYS BROKEN, NOT JUST STALE
------------------------------
The hardcoded client's own captured address is still exactly what it
was after this chapter's own original single-redeploy scenario -
10.0.0.5:8080, the very first address. A second redeploy didn't make
its situation any better OR any worse; it was already completely
disconnected from reality after the first redeploy, and staying
disconnected through a second one changes nothing about that.

WHY THIS CONFIRMS THE PROBLEM COMPOUNDS FOR HARDCODED CLIENTS
------------------------------
In a real system, a service being redeployed, rescaled, or restarted
isn't a one-time event - Chapter 1's own horizontal scaling implies
this could happen repeatedly, even routinely. A hardcoded client
doesn't get "a little more broken" with each redeploy - it was
completely broken after the very first one, and every subsequent
redeploy simply confirms that hardcoding an address was never a
survivable strategy for a system that scales.

WHY THIS WORKS AS AN ANSWER
------------------------------
A second redeploy is added on top of this chapter's own existing
scenario using the identical ServiceRegistry unmodified, and both
clients' own behavior is verified directly after both redeploys rather
than assumed to extrapolate from the single-redeploy case.