[#240] Fix contract address backfill for pre-redeploy data

[realproject7]

Summary

• Migration 00009 incorrectly defaulted existing rows to the new contract address (0x6b8d...)
• All pre-redeploy data was actually created on the old contract (0x05c4...)
• New migration 00012 re-tags all 6 tables back to the correct old contract address
• Operator action needed: Run the same SQL manually against Supabase to fix production data immediately

Test plan

• Migration applies cleanly
• Old data tagged with old contract address (0x05c4...)
• Home page shows empty (no storylines on new contract yet)
• Old data still queryable with old contract address filter

Fixes #240

🤖 Generated with Claude Code

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The migration matches the issue write-up, but as written it is not environment-safe. It blindly rewrites every row tagged with the new contract address, so any environment that has already indexed legitimate new-contract data will have that data silently corrupted back to the old address.

Findings

• [high] 00012_fix_contract_address_backfill.sql updates all rows with contract_address = 0x6b8d... across all six tables, with no predicate that distinguishes wrongly backfilled pre-redeploy rows from legitimate new-contract rows.
  • File: supabase/migrations/00012_fix_contract_address_backfill.sql:5
  • Suggestion: make the backfill targetable and provably safe, for example by constraining on a pre-redeploy cutoff (indexed_at/block_timestamp) or on a known bounded data set, rather than rewriting every row with the new address. At minimum, the migration should fail closed unless the operator explicitly confirms the environment contains no real new-contract data.

Decision

Requesting changes because this migration can corrupt legitimate data in any environment where new-contract rows already exist, and the safety assumption is not encoded anywhere in the SQL.

[project7-interns]

Verdict: APPROVE

Summary

Re-review complete. The backfill is now scoped to a concrete pre-deploy cutoff (2026-03-17T09:00:00Z) using the relevant timestamp columns per table, which prevents the migration from blindly retagging legitimate new-contract rows created after that point.

Findings

• None. The migration now encodes the safety assumption that was previously only implicit.

Decision

Approving because the follow-up makes the contract-address backfill fail closed to pre-cutoff data instead of rewriting every 0x6b8d... row indiscriminately. CI was still pending at the time of review.