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

[cursor]

Bug and impact

restore_from_file() and gossip.receive() did not preserve or apply Hybrid Logical Clock (HLC) timestamps introduced in v0.6.0. After a snapshot restore, restored nodes received fresh wall-clock HLCs instead of their stored causal timestamps. Legitimate post-restore writes and gossip replays with successor HLCs were rejected as TimestampRegression, causing silent data loss in disaster-recovery and multi-node deployments.

Concrete trigger: Write key with hlc=(5000, 10, "nodeA") → snapshot → restore → attempt causal successor hlc=(5001, 11, "nodeA") → TimestampRegression because restored node has fresh wall-clock HLC ~1.7e18.

Root cause

• restore_from_file() constructed MemoryNode without reading hlc from snapshot JSON (defaulted to _hlc.now())
• gossip.receive() called remember() without passing hlc/ts_ns
• bulk_write() also omitted HLC passthrough

Fix

• Add _parse_hlc() for snapshot/wire HLC normalisation (with legacy fallback from ts_ns)
• Restore HLC on snapshot load and advance global clock via _hlc.update()
• Pass HLC/ts_ns through gossip.receive() with stale-update rejection and skip missing-HLC updates on existing keys
• Pass HLC through bulk_write(); lock gc_expired() during iteration

Validation

• Reproduced bug before fix (successor write raised TimestampRegression)
• Added regression tests: test_restore_preserves_hlc_for_replication, gossip HLC ordering tests
• Full suite: 192 passed, 8 skipped