OxiMem — a Redis wire on the same engine

OxiMem speaks the Redis RESP protocol on a separate port (`OXIDB_OXIMEM_PORT`) and shares process memory with the document engine. `redis-cli`, `node-redis`, `go-redis`, every Redis client just works. No translation shim.

What's implemented: strings (GET/SET/INCR/EXPIRE), hashes (HSET/HGET/HDEL), sorted sets (ZADD/ZRANGEBYSCORE/ZINCRBY — full O(log N) skip-list semantics), lists, sets, pub/sub (SUBSCRIBE/PUBLISH/PSUBSCRIBE), Lua-free server-side eval via OxiScript. RESP2 and RESP3. The store lives in a single struct (`OxiMemStore`) inside `oxidb-server` — same binary, no extra service.

**The cross-protocol trick.** MQTT v3.1.1 (`OXIDB_MQTT_PORT`) shares pub/sub channels with OxiMem. An MQTT PUBLISH on `sensors/temp` is received by a redis-cli `SUBSCRIBE sensors/temp` — and vice versa. One protocol topology, two wire formats, zero forwarding overhead.

**SQL mirror.** Set `OXIDB_OXIMEM_SQL=true` and writes shadow-publish into OxiDB collections. `SET user:42 {json...}` lands as a document in `_kv_user` and shows up to the SQL parser. So you can dashboard your hot cache with `SELECT count(*) FROM _kv_user WHERE active=true`. The KV side stays the source of truth; the doc side is read-only.

Benchmark notes: single-cmd OxiMem hits 93–101% of Redis 8.6 throughput; pipelined writes beat Redis on the same hardware (one fewer fsync per batch). Bench script under `tests/comparison-redis/`.