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.