GenServer wrapper around Exgit.ObjectStore.Promisor that serializes cache access across processes.

The plain Promisor is a pure value: two concurrent resolve(p, sha_a) / resolve(p, sha_b) calls from the same p each fetch independently and only one caller's grown cache survives — a benign but wasteful cache race.

For workloads that genuinely do concurrent bulk reads against the same repo (a grep agent spawning N tasks, a CI worker hydrating a cache from many branches in parallel), wrap the Promisor in a SharedPromisor:

{:ok, pid} = SharedPromisor.start_link(promisor)

# Both tasks see + grow the same cache, serialized by the
# GenServer. No race, no duplicate fetches.
Task.async(fn -> SharedPromisor.resolve(pid, sha_a) end)
Task.async(fn -> SharedPromisor.resolve(pid, sha_b) end)

The API mirrors Promisor.resolve/2 / put/2 / empty?/1 / fetch_with_filter/3 — each call acquires a GenServer lock, mutates the internal Promisor, and releases.

When NOT to use this

• Single-threaded agent loops. The plain pure-value Promisor is faster (no message-passing overhead).
• Short-lived scripts. The setup cost of spinning up a GenServer is ~200µs, usually more than the work saved.
• Repos you'd rather snapshot. Share the %Promisor{} struct by value; two tasks holding the same struct see the same cache deterministically.

Failure semantics

If the wrapped Promisor call raises (e.g. a transport misconfiguration), the exception propagates through to the caller and the GenServer terminates. Supervise it under a :one_for_one strategy in your app tree if you want auto-restart; callers will need to re-discover the new pid and re-seed if they want state to persist across restarts.

Telemetry

Each public call emits a [:exgit, :object_store, :shared_promisor, op] span event where op is :resolve | :put | :has? | :get. Use this to track lock-contention latency separately from the underlying [:exgit, :object_store, :*] Promisor events.