Exercise 1: Confirming Per-Key Cache Isolation — Possible Solution
====================================================================

THE TEST
------------------------------
Using this chapter's own CacheAsideRepository and a database seeded
with two keys, PROD-1 and PROD-2:

    1. Read PROD-1 five times.
    2. Read PROD-2 once (first read).
    3. Read PROD-2 two more times.

RESULTS
------------------------------
    db.query_count after 5 reads of PROD-1 (should be 1): 1
    db.query_count after first read of PROD-2 (should be 2): 2
    db.query_count after more PROD-2 reads (should still be 2): 2
    cache contents: {'PROD-1': 'Widget', 'PROD-2': 'Gadget'}

Five reads of PROD-1 only ever produced ONE real database query - the
first one, exactly matching this chapter's own finding. The first read
of PROD-2 correctly triggered a SECOND, genuine database query
(query_count went from 1 to 2) - PROD-1 being fully cached had no
effect on PROD-2 needing its own first, real lookup. Subsequent PROD-2
reads then correctly hit the cache too, with query_count staying at 2.

WHY THIS CONFIRMS ISOLATION, NOT JUST "CACHING WORKS TWICE"
------------------------------
This matters because CacheAsideRepository.cache is a single dict keyed
by the lookup key itself - it would be a real bug if, say, the cache
implementation accidentally treated "the cache has been populated at
all" as equivalent to "this specific key is cached." The test confirms
that isn't happening: each key genuinely needs its own first real
query before it benefits from caching, and one key's own cache status
never leaks into another key's own behavior.

WHY THIS WORKS AS AN ANSWER
------------------------------
The test directly checks the specific claim in question (does a
different key still require its own genuine miss) rather than only
re-confirming this chapter's own original single-key finding, and the
query_count is checked at each individual step so exactly where the
one new real query happened is unambiguous.