The split-brain fix worked perfectly! Notice how Machine 2 is just passively
receiving the heartbeat .json file syncs but is no longer fighting for control
or printing Thump.... Machine 1 is now the uncontested master of the monster.
However, Machine 2 is completely silent about the HP changing. Why?
It is practicing aggressive RAM Conservation. Because you haven't typed
monster on Machine 2 yet, it has never loaded /cmds/monster.c into its local
memory. When the CRDT_MUTATION network packet arrives saying "Hey,
/cmds/monster's HP is now 98!", Machine 2 looks in its RAM, says "I don't have
an object called /cmds/monster", and politely drops the packet to save memory.
Let's test this theory with a brilliant little experiment.
The Observation Test
Leave Machine 1 running (so it keeps counting down the HP).
Go to Machine 2 and type monster into the REPL.
Here is what should happen:
 * Machine 2 will finally JIT-compile the .c file and load it into RAM.
 * It will run create() (which will print "Monster spawned").
 * But because of our Split-Brain fix, it will realize Machine 1 already owns
the heartbeat lock, so it will not start thumping.
 * Instead, because the monster is now in RAM, its Inbox Receiver will
suddenly "wake up" and start catching Machine 1's broadcasts.
You should instantly see Machine 2's terminal start printing:
[MESH SYNC] /cmds/monster updated: hp = 81
[MESH SYNC] /cmds/monster updated: hp = 80

Try typing monster on Machine 2 right now and let me know if it suddenly
starts catching the [MESH SYNC] logs! Once we prove this, we can easily tell
the engine to auto-load objects when it hears about them on the mesh.