Documentation

Drives the password-reset store through the full cutover lifecycle (cassandra -> migration-to-postgresql -> postgresql). Reset keys are deterministic per user and a second reset for the same user is a silent no-op, so every phase writes with a fresh user and reads (and verifies) the write of the previous phase. This exercises the writes of all three interpreters (Cassandra, dual-write, Postgres) as well as their reads.

The rows created before the cutover (u1: pure Cassandra write, u2/u3: dual-write) must be served by the pure-Postgres interpreter afterwards — u1 proves the background worker backfilled a row that only ever existed in Cassandra.

u4 also covers the retry edge cases: a wrong code decrements the remaining retries (and refreshes the row's expiry), and exhausting the retries deletes the row, after which even the correct code is rejected and the password is unchanged.