fix: resolve config defensively in raw runPersistent export
The exported runPersistent(db, config, options) from @atmo-dev/contrail
silently skipped grouped relation count updates when passed an
unresolved ContrailConfig. Internals (applyEvents' buildBatchCountStatements,
query planning, etc.) read `config._resolved?.relations[...]?.groups` —
if `_resolved` was missing, the grouped-counts loop never ran, so columns
like count_rsvp_going stayed at 0 while total count_rsvp updated normally.
The Contrail class constructor resolves the config, so callers going
through `new Contrail(...).runPersistent()` were fine. Only the raw
export was affected — a real footgun for library consumers.
Fix: mirror what Contrail's constructor does and defensively call
resolveConfig when `_resolved` is absent. resolveConfig is idempotent,
so this is a no-op for already-resolved configs.
Regression test in packages/contrail/tests/persistent.test.ts passes a
raw ContrailConfig with a grouped relation and asserts
count_rsvp_going = 1. Confirmed to fail without this patch.
Reverts the Contrail.runPersistent() workaround in the postgres-devnet
e2e tests — they now call the raw runPersistent export directly, same
as any external library consumer would.