harden round 3 — overflow, DoS, correctness fixes

[kacy]

summary

third round of hardening from a full codebase audit. addresses 11 issues across 5 crates:

high severity:

• saturating arithmetic for EXPIRE/PEXPIRE timestamps (prevents u64 wrap on large TTLs)
• checked negation for DECRBY i64::MIN (prevents panic on overflow)
• safe read helpers for gossip message decoding (prevents panic on truncated messages)
• element count + bulk string length limits in RESP3 parser (prevents allocation bombs)
• buffer limit and idle timeout for subscriber mode (prevents memory exhaustion)
• decrement expiry_count when hdel/srem auto-delete empty containers

medium severity:

• 10s timeout on TLS handshake (prevents slowloris-style connection exhaustion)
• reject RENAME when keys hash to different shards (prevents silent data loss)
• saturating_add for gossip incarnation counter (prevents u64 wrap)
• capped Vec::with_capacity in AOF and snapshot parsing (prevents OOM from corrupt count fields)
• fsync parent directory after snapshot atomic rename (ensures rename durability)

what was tested

• full test suite: cargo test -p emberkv-core -p ember-persistence -p ember-server -p ember-cluster -p ember-protocol — all pass
• cargo clippy --workspace -- -D warnings — clean
• cargo fmt --all -- --check — clean

design considerations

• capped_capacity uses 65,536 as the pre-allocation ceiling — large enough for any legitimate single record, small enough to prevent OOM from corrupt u32 values. the loop still iterates the full count, so valid large collections work correctly (just with a few extra reallocations).
• RENAME cross-shard check uses a new Engine::same_shard() method rather than exposing the internal shard_index function. concurrent mode (DashMap) doesn't need this check since it's thread-safe.
• directory fsync after snapshot rename uses best-effort (let _ =) — a failure here shouldn't abort the snapshot since the data is already on disk.