Whole-batch metadata (:meta-all), and refuse a meta map that names no key

[whilo]

The bug

(k/multi-assoc store kvs (k/uniform-meta (keys kvs) {:immutable? true}) opts)

silently dropped the annotation whenever the keys were 2-element vectors — [:a 1], ["user" 7], [:db :root].

uniform-meta has to derive the keys from its argument, and it separates "seq of [k v] pairs" from "seq of keys" by asking whether the first element is sequential with count 2 — which such a key also is. So it returned {:a …}, (get meta [:a 1]) was nil, and every value was written without the metadata. No error.

Found while investigating why konserve-lmdb could not exploit :immutable? to skip its metadata read.

The heuristic cannot be fixed, and this PR does not try

[[:a 1]] is both a valid one-key seq and a valid one-pair seq — the same data. Narrowing the test to MapEntry was implemented and reverted: it fixes (keys m) and breaks the hand-built pair-vector instead, which only moves the failure onto a different caller. The compliance suite has one (4 failures).

So the need to guess is removed, and the guess is made non-silent.

Changes

{:meta-all m} in opts annotates the whole batch. It carries no keys, so it cannot misread them, and it is the majority case — bulk content-addressed writes. Passing both meta and :meta-all throws.

multi-assoc refuses a per-key meta disjoint from kvs (:konserve/meta-keys-disjoint). That is always a mistake and is the exact signature of a misread shape, or a typo in a hand-built map. Partial overlap stays legal — annotating a subset is the documented mixed-batch case (immutable nodes plus the mutable pointer that makes them reachable).

Hooks see one shape. :meta-all is expanded into the per-key map at the write-hook boundary and never escapes konserve.core, so konserve-sync needs no change — it keeps its (get m k). Teaching every consumer a second spelling would recreate the dropped-annotation bug one layer out. Expansion happens only when a hook is registered, so the write path still avoids building an N-entry map to say one thing.

uniform-meta is unchanged, with its docstring now stating that its shape test is a guess that cannot be made sound, and pointing at :meta-all.

Why it matters

konserve-lmdb uses :meta-all {:immutable? true} to skip the metadata read-modify-write that konserve's contract otherwise requires — a content-addressed value is written once, so there is no prior metadata worth merging:

	µs/key	batch put
ordinary batch	52.6	91.8K ops/s
:meta-all {:immutable? true}	27.0	163K ops/s (1.78x)

That is datahike's node-storage shape.

Verification

123 tests, 1399 assertions, 0 failures. Behaviour verified end to end against konserve-lmdb, which is multi-key capable where the memory store is not (Store does not support multi-key operations, so the guard is unreachable there):

• disjoint meta raises :konserve/meta-keys-disjoint
• :meta-all round-trips to get-meta
• subset annotation still allowed

Scope note

This branch also carries three pre-existing local commits that were not on origin/main: ada3aa6 (boring 0.1.17), 57edebd (serializers: encode-indexed), 1c5c9e8 (README backends). Happy to rebase them out if you would rather they land separately.