async-state-consistencylisted

# Async State Consistency Use for language-neutral component state whose asynchronous work can race with clear, invalidation, expiry, refresh, another publication, or a direct caller. ## Contract First Before proposing a repair: 1. Name the authoritative state holder and every path that can return, publish, replay, or repopulate it: observers, late subscribers, warm cache, one-shot calls, memoization, request coalescing, persistence, and derived projections. 2. Model lifecycle states explicitly. Keep initial or unknown distinct from `Available(empty)`, and define invalidated, error, stale, and retry outcomes only where the contract needs them. 3. Name each ownership domain: global invalidation generation, keyed/domain generation, ordinary publication revision, operation identity, and any dependency revisions. 4. Choose and name the supersession policy for competing work: latest-start-wins or latest-success-wins. Define what happens to older work when a newer attempt fails or is cancelled. 5. Choose a separate same-generation admission policy: join/coalesce one shared operation, queue/serialize distinct attempts, or run independently. 6. For shared work, distinguish cancellation of one waiter from cancellation requested for the shared entry, and define when that entry stops being joinable. 7. Define the direct caller outcome when its work is rejected: authoritative reread, declared stale/retry/cancellation, or another explicit result. 8.