fix: renumber migrations to fix staging deployment

[tadasant]

Summary

Fixes staging deployment by renumbering migrations to match what staging has already applied.

Problem

Staging already applied migration 008 (metadata separation) before we inserted the new cleanup migration. When we added the cleanup as 008 and renumbered metadata to 009, staging tried to apply 009 again and failed with "column already exists".

Current State

• Staging: Has run original 008 (metadata separation), marked as complete. Failed trying to run 009 (which is the same migration renumbered).
• Production: Has not run either 008 or 009 yet.

Solution

• Rename 008_clean_invalid_data.sql → 007a_clean_invalid_data.sql
• Rename 009_separate_official_metadata.sql → 008_separate_official_metadata.sql (back to original)

How This Fixes It

With this renumbering:

1. Staging behavior:

   • Sees 008 is already complete (the metadata migration it already ran)
   • Sees 007a as new and runs it, but it will be a no-op (skips because staging doesn't have the problematic production data)
   • Continues normally

2. Production behavior:

   • Runs 007a (cleanup migration) - removes invalid data
   • Runs 008 (metadata separation) - applies successfully because data is now clean
   • Both migrations run in the correct order as intended

Testing

• Verified migration order works correctly
• Tested on empty database (test environment) - 007a skips as expected
• Tested with production data snapshot - 007a cleans data, 008 applies successfully

This is a critical fix to unblock staging deployment.