fix(rust_brain): preserve HLC on snapshot restore and gossip receive

[cursor]

Bug and impact

After snapshot restore, restore_from_file() assigned fresh HLC timestamps to every node instead of restoring the stored values from the snapshot. This caused silent data loss in disaster-recovery and multi-node gossip scenarios:

1. Post-restore writes rejected: Legitimate causal successor writes (e.g. hlc=(5000, 11, 'nodeA') after a node stored at (5000, 10, 'nodeA')) raised TimestampRegression because restored nodes got a fresh wall-clock HLC.
2. Gossip replay dropped: After a node restarted from snapshot, gossip events carrying pre-crash HLC timestamps were silently rejected, losing replicated memory updates.

Root cause

restore_from_file() created MemoryNode without passing the hlc field from the snapshot JSON. gossip.receive() also omitted HLC when calling remember(), and bulk_write() did not pass HLC through.

Fix

• Add _parse_hlc() to normalise HLC from snapshot/wire form (list or tuple)
• Restore HLC on snapshot load and advance the global _hlc clock
• Pass HLC through bulk_write and gossip.receive
• Reject stale gossip updates; skip HLC-less updates on existing keys
• Hold _lock during restore to prevent concurrent mutation

Validation

• Reproduced: restore assigned fresh HLC instead of snapshot (5000, 10, 'nodeA'); causal successor write raised TimestampRegression
• New regression tests: test_restore_preserves_hlc_for_replication, gossip HLC ordering tests
• Full suite: 192 passed, 8 skipped