sec(api): delayed token approval validates the execution snapshot, not the token hash at the status change #590

Found in the review of PR #589 (closed #586). approveViaToken validates the approval token against the execution loaded at the start of the request, then approveWithDelay does a status CAS that filters on status only, not on the token hash. A token rotated between the load and the CAS (re-notification, internal/purchase/notifications.go ~164) could still pass for a few milliseconds; the immediate path re-reads inside ApproveExecution. Practical risk is negligible (same tenant, same contact). Also: the approval token hash stays on the row after scheduling (replay is blocked by the CAS, and the cancel CAS rejects scheduled rows), and the new delayed-approval tests are mock-based, not real Postgres.

Acceptance: validate against the row inside the transition (re-read, or CAS on the token hash), with a test that rotates the token between load and CAS; optionally clear the hash on scheduling and add one real-Postgres test of the delayed approve route. Related: #586, #589, #584.