fix: unblock v0.29.1 effective date migration

[sanchalr]

Summary

• connect the v0.29.1 migration's Phase B/Phase C engines before calling executeRaw
• remove raw BEGIN/COMMIT/ROLLBACK from the effective-date backfill loop
• rely on the existing idempotent, checkpointed row updates instead of a batch-level transaction

Why

On a Postgres install, gbrain apply-migrations --yes can remain permanently PARTIAL for v0.29.1:

1. createEngine(...) returns an unconnected engine, so Phase B/Phase C can fail with No database connection: connect() has not been called.
2. After connecting manually, the backfill's raw BEGIN on the postgres.js pooled connection can fail with UNSAFE_TRANSACTION: Only use sql.begin, sql.reserved or max: 1.

The backfill is already safe to run as independent updates: it is deterministic, idempotent, skips equal rows, and checkpoints by backfill.effective_date.last_id after each batch.

Verification

Run locally against a Postgres-backed gbrain install that was stuck on v0.29.1 partial:

bun run typecheck
gbrain apply-migrations --yes
gbrain doctor --json

Results:

• bun run typecheck passed
• gbrain apply-migrations --yes changed v0.29.1 from PARTIAL to complete
• gbrain doctor --json no longer reports minions_migration failure
• remaining doctor warning is unrelated sync_failures FK noise from stale source IDs

---

^{Need help on this PR? Tag @codesmith with what you need.}

• Let Codesmith autofix CI failures and bot reviews