fix(setu-vlc): don't report causally-equal clocks as concurrent

[Alicepoltora]

Fixes #39.

Problem

VectorClock::is_concurrent decided concurrency with !self.happens_before(other) && !other.happens_before(self) && self != other. The self != other term is a structural HashMap comparison, whereas happens_before correctly treats a missing node as an implicit 0. Two clocks representing the same causal state but differing only by an explicit zero entry were therefore reported as concurrent:

VectorClock::with_node("a".into()) /* {a:0} */ .is_concurrent(&VectorClock::new() /* {} */) // was: true

Such explicit zeros are produced by the crate's own API (with_node, set(_, 0), reset_node, VLCSnapshot::for_node), so this is reachable in normal use and can cause spurious conflict detection in the consensus/causality layers. VLCSnapshot::is_concurrent delegates here and inherits the fix.

Fix

Reimplement is_concurrent by scanning the union of node ids with implicit-zero semantics: two clocks are concurrent iff one is strictly greater at some node and strictly less at another. This no longer depends on structural equality, so causally-equal clocks are correctly treated as equal (not concurrent). No other behavior changes — ordered and genuinely-divergent pairs are classified exactly as before.

Tests

Adds regression tests: explicit-zero equal cases ({a:0} vs {}, {n:3} vs {n:3,m:0}) now return false; divergent pairs still true; ordered and empty pairs false; symmetry check. Verified locally: cargo test -p setu-vlc green, cargo clippy clean, added code rustfmt-clean.

Notes

Only the is_concurrent body and a #[cfg(test)] module are touched; no public signatures change. Complementary to the test-coverage PR #38 (they can be rebased in either order).