fix: schema-drift check compared against wrong table + stale Neon DB

[Skeyelab]

Two bugs, one always-red workflow

1. collect.ts read migration history from drizzle.__drizzle_migrations, which only exists when drizzle-kit migrate runs directly. Production applies migrations via the app's own applyCommittedMigrations(), tracked in public.__clawproxy_migrations — a table drizzle-kit never touches. The check was querying a table that doesn't exist in prod's migration flow.

2. DRIFT_CHECK_DATABASE_URL was set up ~11h before PR feat: move auth to Coolify Postgres #88 (move auth to Coolify Postgres) merged, so it still pointed at the old Neon DB. Neon stopped receiving writes once the app cut over, so the check was permanently comparing against a frozen pre-cutover snapshot.

Fix

• collect.ts now reads public.__clawproxy_migrations.
• New scripts/schema-drift/apply-migrations.ts + db:drift:seed-expected seeds the CI throwaway DB using the app's real migrator, so both sides of the diff use the identical mechanism production uses.
• Rotated DRIFT_CHECK_DATABASE_URL to a new least-privilege read-only role (clawproxy_drift_ro, SELECT-only, no write access) on the current Coolify clawproxy-postgres instance, and made that DB briefly publicly reachable (was previously LAN-only) so GitHub Actions can reach it.

Verified

Ran the full check locally against real production:

✓ production matches the migrated schema (50 columns, 21 indexes, 6 migrations)

Test plan

• yarn lint
• yarn test:run (289 passed)
• Local end-to-end drift check against prod (passed, see above)

[strix-security]

Strix Security Review

No security issues found.

Review summary

Reviewed the schema-drift check fix, which corrects the migration-history table (public.__clawproxy_migrations) and introduces a CI seeding script (apply-migrations.ts) that applies committed migrations via the same mechanism as production. The changes are minimal and correct: the new script sources its connection string from the environment, the modified query is a static parameterized statement with no attacker-controlled input, and the workflow only swaps the expected-schema build command. No hardcoded secrets, injection vectors, or authorization changes were introduced. Static analysis (semgrep) surfaced no findings.

_{Updated for cb28021.}

---

Reviewed by Strix
_{Re-run review · Configure security review settings}