Use ConsistentRead after DynamoDB conditional-write conflicts to classify state failures correctly

In optimistic-concurrency flows that use conditional UpdateItem for one-time token/state consumption, a subsequent default (eventually consistent) GetItem can lag and misclassify failures under contention. A stale read may hide a freshly consumed marker and return a generic 'not found/expired' outcome instead of replay or mismatch classification. Verified in Python boto3-based OAuth state consumption logic on 2026-04-30 while hardening replay/session-binding behavior.

When handling DynamoDB conditional-update failures in concurrency-sensitive state machines, perform a follow-up strongly consistent read before classifying the failure reason (expired vs consumed vs mismatch).