BigDecimal support via dbval's own tuple encoding

[maxweber]

Replaces the FoundationDB tuple layer with dbval's own order-preserving encoding that supports BigDecimal (Tobias's #15, merged into this branch), plus the fixes from the deep review of that PR.

Review fixes on top of #15

Correctness

• store-slatedb compiles again: blob-key still used the FDB Tuple class, whose dependency moved to the root :dev alias that a :local/root consumer never activates. Now encoded via dbval.tuple (byte-identical, existing SlateDB files stay readable).
• Compact decimal encoding: canonical-decimal called .setScale 0, materializing trailing zeros — 1E+100000M became a 100 KB index key (written 4×/datom), 1E+999999999M ~1 GB (transactor OOM), 1E+2147483647M an opaque ArithmeticException. Now encoded from the stripTrailingZeros form: 1E+100000M is 8 bytes and transacts in microseconds. Decode-side integer restoration is bounded, and adjusted exponents beyond int32 are rejected instead of wrapping the offset encoding.
• One canonical representative everywhere: deref attributes hashed the scale-sensitive pr-str, so (d/datoms db :eavt e attr 0.50M) missed a stored 0.5M and [:db/retract e attr 0.50M] silently no-oped on it; :tx-data carried 19.90M while every read returns 19.9M. dbval.tuple/canonical-value is now applied in transact-add and value->blob-ref, so index bytes, blob hashes, tx-data and reads agree.
• Unpaired surrogates rejected: String.getBytes silently replaced them with ?, aliasing distinct strings (e.g. a caption truncated mid-emoji) to identical keys and blob hashes. fdb-java's reject-loudly policy is restored.
• NaN payloads packed raw like fdb-java; doubleToLongBits canonicalized every NaN, breaking byte compatibility and re-encode idempotency for legacy NaN datoms.

Hardening

• Decimal size cap: the raw decimal encoding (1 byte/significant digit) bypassed max-inline-value-bytes; a digit-count bound now raises the same :transact/value-too-large as oversized strings, protecting SlateDB's 64 KiB key limit.
• Type validation at the boundary: the supported-type policy lived in three drifting conds, and transacting a Ratio surfaced as set-add! failed → pack failed with the datom dumped into logs. dbval.tuple/supported-value? is the single source of truth; serialize-value raises :transact/unsupported-value-type with the attribute and a {:dbval/deref true} hint, and tuple-list passes all :transact/* anomalies through unwrapped.
• Type code moved 0x23 → 0x40: the FDB spec reserves 0x23/0x24 for a future incompatible decimal; 0x40-0x4F is its third-party range. Free now (no released store contains decimal bytes), a data migration later.

Performance (hot paths: pack runs 4×/datom per transact + per range bound)

• pack writes through an unsynchronized growable buffer with bulk-copied escape chunks instead of a synchronized ByteArrayOutputStream one byte at a time: ~4× faster on a representative eavt key (5.3 s → 1.2-1.4 s per 1M packs).
• unpack bulk-copies escape-free regions and builds strings directly on the source array.
• Dropped the tuple vec alias and the FDB-era per-datom vector copies (tuple-list output now feeds pack directly).

Post-review hardening (from a second audit pass)

• Unpaired-surrogate strings now raise :transact/invalid-string with the attribute at the serialization boundary instead of a wrapped pack failed chain with the datom in ex-data.
• Strings nested inside tuple values obey the same size/surrogate guards as top-level values (a 70 KB nested string used to bypass validate-inline-size and silently write a 70 KB key).
• set-add! checks the packed key against a 64 KiB max-key-bytes backstop — components can each pass the per-value caps and still sum past SlateDB's key limit (e.g. a composite tuple of three 40 KB strings).
• The bound-value pushdown decision is a streaming type check; the distinct bound values are only materialized once the pushdown is chosen.

Docs: byte-compat claim scoped to the types dbval ever wrote (Versionstamps excluded); documented that stores from the FDB era may hold BigDecimal/large-BigInt datoms truncated to longs by the old Number.longValue() fallback (they need a scan-and-reassert on upgrade); README no longer credits the FDB Tuple class with the encoding.

Verification

• Full suite: 206 tests / 1237 assertions green; store-slatedb suite green on a classpath without fdb-java (previously failed at namespace load).
• New generative coverage: decimal ordering specs now include exponents up to ±1E5; NaN bit patterns pinned against the fdb-java oracle; surrogate, size-cap, unsupported-type, tx-data-scale and deref-scale regressions each have a test.
• Pre-landing, the compact decimal encoding was property-tested standalone: 120k+ ordered pairs (byte order == numeric order), canonicality, round-trip idempotency.

Query engine: bound values against deref attributes (pre-existing bug, also fixed here)

[?e :attr ?v] with a bound ?v found nothing for deref attributes — the pattern relation carried BlobRefs that never hash-join against raw bound values — and bound BigDecimals failed to join across scale representations, because hash-join buckets by the scale-sensitive hashCode while = is scale-insensitive. lookup-pattern-db now detects these two cases and looks the pattern up once per distinct bound value, binding the v column to the bound value so the join matches (also an index seek instead of an attribute scan). All other shapes keep the scan-and-hash-join path, including deref-to-deref joins, whose BlobRef columns already joined correctly.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UHpAtiY7bGbGJLYsYKdDvf