Add concurrency building blocks: delta inboxes, sharded counter, revocable membership tree

🧐 Motivation

Every hot read-modify-write of a shared ledger cell serializes writers: the in-circuit read is pinned into the transcript, so concurrent writers reject each other. The note token hit this on supply and on the KYC allowlist, and the fix is not token-specific — it belongs in utils/.

📝 Details

contracts/src/utils/concurrency/, with per-module docs and the analysis in the repo-root concurrency.md.

• UintDeltaInbox — splits a hot counter into credit (hot, must commute) and absorb (cold, may serialize). Writers blind-insert deltas keyed by their own randomness, reading no ledger value; a fold drains up to 8 entries and returns the netted delta. Only the fold conflicts, and only with itself.
• ElGamalDeltaInbox — the same split for exponential-ElGamal accumulators (encrypted supplies, encrypted balances); the fold returns the homomorphic sum for the consumer to absorb.
• ShardedCounter — add-only Uint<128> total split across shards, for counters the kernel Counter cannot carry (its increment is capped at Uint<16> per call). Probabilistic: a 1/N collision instead of certainty. For folderless deployments.
• RevocableMembershipTree — ZK membership where additions do not invalidate in-flight proofs but removals still revoke instantly: proofs check the historic root set, _add appends, _removeAt tombstones then calls resetHistory().

Landed in #679 (draft).

Read the repo-root concurrency.md and inspect contracts/src/utils/concurrency/ to understand the four proposed building blocks and their per-module documentation. Check #679 (draft) before starting, since the issue says this work landed there. Done means the specified inboxes, sharded counter, revocable membership tree, and accompanying docs are implemented consistently with that analysis.