concurrency-invariantslisted

# Concurrency Invariants Name the guarantee before choosing a mutex, retry, transaction, lease, or idempotency key. Match the repo's architecture; do not force a framework or clarity-first redesign. ## Choose scope - **Review:** findings only. Give a possible interleaving and observable impact, not `there may be a race`. - **Fix / design:** enforce every live part of the contract below. Preserve APIs and local shape unless the guarantee requires a new seam; disclose it. ## Build the contract before editing Answer only what is live, but inspect every line: 1. **Guarantee:** What must be impossible or remain true? 2. **Ownership:** Which component owns each state and effect? Is coordination process-local, shared, or remote? 3. **Commit points:** What changes atomically? Which effects cannot share that boundary? 4. **Replay:** What can run again? What stable identity follows one logical operation to the owner that deduplicates it? 5. **Scheduling:** What may overlap or reorder? What needs per-key serialization or fencing? 6. **Interruption:** At each timeout, cancellation, or failure boundary, what may already have happened? What is pending, and who resumes or compensates? A timeout or lost response is an unknown outcome unless the API proves the effect was not applied. Name only guarantees the mechanisms really provide. ## Enforce every boundary - Inside one owned store, use its transaction, compare-and-set, or uniqueness primitive when needed. - A process-local lock p