Approval consumption is not compare-and-set, so concurrent resumes can race #121

_resume_ssp_distribution marks an approval consumed before creating the deal, but storage has no compare-and-set, so two truly simultaneous resumes can both pass the status check and both call create_deal (documented in a comment in approval_service.py). Additionally, if the racing duplicate create fails, the failure handler restores approved over the winner's consumed. Proposal: add an atomic transition to the storage interface (or a per-approval lock) and make the failure handler restore only if the status is still the one it set. Follow-up to #111.