feat(gc): the safe point belongs to the store

[whilo]

The race

A persistent index on konserve writes every value the new state references and only then the pointer that makes them reachable. That ordering is what makes a torn write leave collectable orphans rather than a dangling pointer.

It is also a blind spot for the collector. Inside that window the fresh values are reachable from nothing while already being older than now — so a sweep cutting off at now deletes them, and the pointer then lands on holes. A timestamp cutoff cannot save you here, because the objects genuinely predate the collection.

Why it belongs in konserve

datahike has carried a private guard for this. It shouldn't.

One konserve store commonly carries several independent index structures — a datahike database, a geschichte repository, a scriptum fulltext index — each running its own values-then-pointer sequences, and one sweep covers all of them. A guard held inside one library cannot protect the others. The safe point is a property of the store, and it is shared by agreeing on a store-id.

What changed

• konserve.gc-guard — writing! / done! / in-flight? / safe-point / cutoff / with-unreferenced-writes, keyed by store-id, stamped from the existing monotonic write clock (konserve.utils/now).
• konserve.gc/sweep! takes :store-id and derives its own cutoff as min(ts, safe-point) rather than trusting the caller's ts. Combining those two readings is easy to get wrong — the guard must be read after the collection's start instant, or a sequence opening in between is missed — so that reasoning lives once, next to the sweep. Without :store-id behaviour is unchanged, so this is backwards compatible.

Scope is in-process, matching konserve's concurrency contract (single writer per runtime, or coordinate above konserve). Documented on the namespace.

Tests

The tests assert the property rather than the bookkeeping: the same sweep over the same in-flight sequence eats its values unguarded and spares them guarded, and a sweep triggered by one writer spares another writer's in-flight values on a shared store.

Two things worth flagging for review, both learned the hard way here:

• Cutoffs are derived (successor of the high-water mark), not observed. The write clock is pinned to wall time, so a cutoff read straight after a write ties with it about half the time and the sweep spares ties — the first version of this test was flaky for exactly that reason.
• Where the clock does have to move, the global high-water mark is restored afterwards. It is max-based and process-wide, so leaving it advanced makes every later test stamp ahead of wall time; unrestored, it broke monotonic-clock-test and async-gc-test in the same run.

Full suite green three consecutive runs: 87 tests, 1310 assertions.

Follow-ups (not in this PR)

datahike should drop its local copy and call this one — in the same release, so the two cannot disagree about the clock. scriptum and proximum need the guard around their own values-then-pointer sequences.

[whilo]

Follow-up: the store now names itself (53da620)

Investigating whether sweep!'s :store-id argument could come from the store's config instead turned up something better and slightly alarming.

The id is validated and then thrown away. validate-store-config requires a UUID :id on every store, and no backend retains it. Verified empirically:

(let [s (ks/create-store {:backend :file :path "..." :id id} {:sync? true})]
  (:id s)               ;=> nil
  (get-in s [:config :id])  ;=> nil
  (keys (:config s)))   ;=> (:in-place? :lock-blob? :sync-blob?)

A DefaultStore's :config holds the backend's behaviour options, not the store's identity — the UUID appears nowhere on the record at all. And this isn't a backend gap: konserve-lmdb has its own LMDBStore that explicitly "Bypasses DefaultStore", so there was no shared field to read even in principle.

Which means anything that had to name a store was handed the name separately and had to keep it in agreement by hand. Two components naming one physical store differently is invisible until a collection deletes something — a poor property for the mechanism whose entire job is deciding what may be deleted.

PStoreIdentity

Added to konserve.protocols, following the PMultiKeySupport idiom (protocol + Object default):

(p/-store-id store)   ; or konserve.store/store-id

The default implementation reads an id that konserve.store/connect-store/create-store attach — the one place every backend passes through with the full config in hand, LMDB included, since dispatch happens there. So no backend has to change. A backend that would rather hold its id in a real field can implement the protocol and become authoritative.

Effect on sweep!

It now derives the id and consults the guard by default. :store-id remains for stores built through a backend constructor directly (connect-fs-store and friends), which never took an id to begin with.

Both paths are tested. The derived-id test proves the emptiness came from the guard rather than from a sweep that never ran, by collecting the same value once the sequence closes.

JVM 90 tests / 1318 assertions, node 50 / 319 — both green.