fix(deploy): make 0001_init.sql re-runnable and repair historical _migrations tracking

The "Run migrations" job (and thus the whole deploy) was failing on every push after the first successful bootstrap with:

  ✗ 0001_init.sql failed: relation "admin_users" already exists

Root causes:
- 0001_init.sql used plain CREATE TABLE/INDEX/TRIGGER despite the header comment claiming "CREATE TABLE IF NOT EXISTS".
- The _migrations tracking row for 0001_init.sql was never recorded on the prod DATABASE_URL (tracking logic landed after initial apply, or apply happened outside the runner).

Fix (3 layers of defense):
* db/migrations/0001_init.sql: every CREATE TABLE now uses IF NOT EXISTS (63 tables), CREATE INDEX uses IF NOT EXISTS (49), all CREATE TRIGGER wrapped in safe DO $$ IF NOT EXISTS (pg_trigger join check) THEN ... END IF; $$, removed the file's own BEGIN/COMMIT so the runner's transaction is authoritative. RLS drop+create and CREATE OR REPLACE FUNCTION were already safe.
* scripts/migrate.js: added ensureTracked() right after loading the applied set. For 0001/0002, if the core objects (admin_users table, password_hash column) already exist in information_schema but the tracking row is absent, INSERT the filename (ON CONFLICT DO NOTHING) and log "repaired tracking". Then the normal skip path handles it.
* .gitea/workflows/deploy.yml: added an inline node -e pre-repair (same admin_users existence check → force _migrations row) immediately before `npm run migrate:one`. This protects even on an older checkout of the runner. The neon_auth preflight and post-apply "admin_users must exist" hard gate are untouched.
* Minor: cleaned 0002_admin_password.sql tx wrapper for consistency; updated MEMORY.md with the incident + resolution.

Result: deploys (and any server-side `node scripts/migrate.js` recovery runs) on an already-initialized prod DB will repair/skip 0001 cleanly, pass the verification query, and continue to build/deploy. The scp of scripts/ + db/migrations/ in the Deploy step now carries the fixed versions.

See the plan note in deploy.yml and MEMORY.md for background.

.gitea/workflows/deploy.yml

@@ -48,6 +48,34 @@ jobs:
               .catch(e => { console.error("Pre-flight check failed:", e.message); process.exit(1); });
           '
           echo "=== Running migrations against DATABASE_URL (masked value for logs) ==="
+          # The migrate runner (scripts/migrate.js) now includes repair logic for
+          # DBs that had 0001_init.sql applied before _migrations tracking was added.
+          # We also run a tiny pre-repair here so the step is resilient even if an
+          # older copy of the runner is present in the checkout.
+          node -e '
+            const { Client } = require("pg");
+            const url = process.env.DATABASE_URL;
+            if (!url) { process.exit(0); }
+            const c = new Client({ connectionString: url });
+            c.connect()
+              .then(() => c.query("SELECT 1 FROM information_schema.tables WHERE table_name = '\''admin_users'\'' LIMIT 1"))
+              .then(async (res) => {
+                if (res.rows.length > 0) {
+                  await c.query(`
+                    CREATE TABLE IF NOT EXISTS _migrations (
+                      filename TEXT PRIMARY KEY,
+                      applied_at TIMESTAMPTZ NOT NULL DEFAULT now()
+                    );
+                    INSERT INTO _migrations (filename)
+                    VALUES ('\''0001_init.sql'\'')
+                    ON CONFLICT (filename) DO NOTHING;
+                  `);
+                  console.log("✓ 0001_init.sql tracking repaired (admin_users already present)");
+                }
+                return c.end();
+              })
+              .catch(() => { /* best effort */ });
+          '
           npm run migrate:one
           echo "=== Post-migration verification: critical table admin_users must exist ==="
           node -e '