sec(approvals): hash approval tokens on purchase/ri_exchange paths #71

Summary

The commitment-laddering schema PR (LeanerCloud/cloud-commitments-cli#1355) stores its run approval token as a SHA-256 hash (ladder_runs.approval_token_hash, migration 000080), never in plaintext. The pre-existing approval-token columns on the older purchase / RI-exchange paths still store raw tokens and should be hardened the same way:

• purchase_executions.approval_token (raw VARCHAR(255))
• ri_exchange_history.approval_token (raw VARCHAR(255))

Storing raw approval tokens means a read of the DB (backup leak, SQL injection, over-broad read grant) hands an attacker working approval links. Hashing at rest closes that: the raw token lives only in the emailed approval link; the DB holds only its digest.

Scope

1. Add hashed columns (approval_token_hash TEXT) alongside the existing raw columns via an expand-contract migration (add hashed column, backfill on next issue/rotate, switch writers to hash-on-write, then drop the raw column in a later contract migration).
2. Change the writers on both paths to store sha256(token) and the verifiers to constant-time-compare the hash (crypto/subtle), matching the pattern the ladder email-approval PR (phase-3 PR-3) will introduce for ladder_runs.approval_token_hash.
3. Do not weaken token entropy or expiry; this is storage-at-rest hardening only.

Context

Split out of LeanerCloud/cloud-commitments-cli#1355 CR review (F3) so the pre-existing raw-token gap is tracked rather than silently masked. The ladder path already does the right thing; this brings the two older paths to parity.

Refs LeanerCloud/cloud-commitments-cli#1333