feat(migration): add up and down migration for password_hash column

[leandromasotti]

Fix duplicate migration filenames (#203)
Two migration pairs shared the same 2026061001 date counter, violating the YYYYMMDDNN_<description>.{up,down}.sql convention that requires a unique <NN> per day.

Changes

• Renamed (via git mv, history preserved): 2026061001_add_user_password_hash.{up,down}.sql → 2026061002_add_user_password_hash.{up,down}.sql.
• Kept 2026061001_add_password_hash as the canonical migration — it's the one that matches database/schema.sql exactly (password_hash VARCHAR(255) NOT NULL, no default). The renamed pair uses NOT NULL DEFAULT '', which diverges from the schema.
• Updated the internal header comments in the renamed files to 2026061002.
• Updated database/migrations/README.md: completed the migration listing table and added a note explaining the 01/02 relationship and referencing this issue.

Acceptance criteria
✅ Each migration pair now has a unique counter: 2026051501, 2026061001, 2026061002.
✅ Applying migrations in order reproduces schema.sql: 01 creates password_hash VARCHAR(255) NOT NULL (no default); 02 becomes a no-op via IF NOT EXISTS. Final state matches the schema.
✅ Migration documentation is up to date.

Heads-up / open question
Both migrations add the same users.password_hash column, so 2026061002 is effectively a redundant re-add (its up is a no-op after 01). This PR follows the ticket literally by renaming rather than deleting. There's also a minor rollback footgun: the 02 down runs DROP COLUMN IF EXISTS password_hash, so rolling back only 02 would drop the column actually introduced by 01.

If the team prefers, I'm happy to instead delete the redundant 2026061002_add_user_password_hash pair entirely (keeping only the canonical 2026061001_add_password_hash), which removes the no-op migration and the rollback footgun. Just let me know and I'll update the PR.