Exercise 1: Two Unreplicated Keys — Possible Solution
====================================================================

THE TEST
------------------------------
    primary.write('PROD-1', 100)
    primary.write('PROD-2', 200)

Both writes go to the primary, both get queued in write_log, and
neither has been replicated yet.

VERIFYING BOTH ARE MISSING BEFORE REPLICATION
------------------------------
    replica.read(PROD-1) before replication: None
    replica.read(PROD-2) before replication: None

Both keys are genuinely absent from the replica - not one, not
partially applied, both completely missing, confirming write_log
correctly queued both writes without replicating either.

VERIFYING BOTH ARE PRESENT AFTER REPLICATION
------------------------------
    replica.read(PROD-1) after replication: 100
    replica.read(PROD-2) after replication: 200

A single call to replicate_to() correctly applied BOTH queued writes
to the replica in one pass - exactly matching the values written to
the primary.

WHY THIS CONFIRMS write_log HANDLES MULTIPLE PENDING WRITES CORRECTLY
------------------------------
This chapter's own original example only tested a single write. This
exercise confirms write_log genuinely accumulates every write made
since the last replication - not just the most recent one - and
replicate_to() correctly drains all of them together, not just the
first or the last. This matters for a realistic scenario, since a real
primary database accumulates many writes between replication cycles,
not just one at a time.

WHY THIS WORKS AS AN ANSWER
------------------------------
Two independent writes are made before any replication happens, both
are verified missing from the replica beforehand and both verified
present afterward, directly confirming write_log's own batching
behavior rather than assuming it generalizes from the single-write
case.