The bug

Autopilot's per-cycle DB health check (autopilot.ts:248-255) tries to recover from a transient connection failure with:

```ts
try {
await engine.getConfig('version');
} catch {
try {
await engine.disconnect();
await (engine as any).connect?.(); // ← no arguments
} catch (e) { logError('reconnect', e); }
}
```

But `PostgresEngine.connect` requires a config:

```ts
async connect(config: EngineConfig & { poolSize?: number }): Promise {
this._savedConfig = config; // overwrites with undefined
if (config.poolSize) { // → "undefined is not an object (evaluating 'config.poolSize')"
```

So every transient health blip:

1. Wipes `_savedConfig` (corrupting state for future supervisor reconnects too).
2. Throws `undefined is not an object (evaluating 'config.poolSize')`.
3. Logs `[reconnect] ERROR ...`.
4. Leaves the engine without a connection. The next dispatch fails with `No database connection: connect() has not been called`.
5. Cycle marks failed. After 5 in a row: `Autopilot stopping (cycle-failure-cap)`. launchd respawns ~10 s later. Repeat.

The buggy pattern dates to v0.10.1 (b7e3005), well before v0.22.1's #406 added `reconnect()`. It was silent because the catch path only fires on real connection drops; on a healthy pool you never see it.

Real-world impact (one operator's data)

In ~8 days on a Supabase free-tier brain:

• 54 `Autopilot stopping (cycle-failure-cap)` exits.
• ~85 cascading `Errors.postgres` parse errors.
• ~70 `MaxClientsInSessionMode` pool-saturation errors as orphaned backends piled up between launchd respawns.
• ~2,488 cascading per-page embed failures (separate root cause, but they only kept happening because autopilot kept dying mid-cycle).

Every Supavisor pooler keepalive eviction tripped this code and broke the daemon until launchd respawned it.

The fix

Route recovery through `engine.reconnect()` (added in v0.22.1 #406), which uses the saved config instead of dropping it.

```ts
try {
await engine.getConfig('version');
} catch {
try {
if (typeof (engine as any).reconnect === 'function') {
await (engine as any).reconnect();
} else {
await engine.disconnect();
}
} catch (e) { logError('reconnect', e); }
}
```

`reconnect()` already handles the saved-config-missing case (returns early), so this is safe even if `connect()` was never called on this engine. PGLite (which doesn't implement `reconnect`) falls through to a plain `disconnect()`, preserving prior behavior.

Repro

1. `gbrain autopilot --repo ~/brain` against a Supabase Postgres brain.
2. Wait for any transient connection drop — Supavisor pooler restart, network blip, idle-eviction. On a free-tier brain this is usually within an hour.
3. `tail -f ~/.gbrain/autopilot.log` — you'll see `[reconnect] ERROR: undefined is not an object (evaluating 'config.poolSize')` followed by repeated `[dispatch] ERROR: No database connection` every cycle until `Autopilot stopping (cycle-failure-cap)` fires.

Tests

I didn't add a new test in this PR — the change is a single replacement. Happy to add a unit test that mocks `engine.getConfig` to throw and asserts `reconnect()` (not `connect()`) gets called. Let me know.

Related

• The companion PR fix(autopilot): cd into --repo so Bun auto-loads brain/.env #464 fixes a different daemon bug in the same area (`autopilot-run.sh` doesn't `cd` into the brain, so Bun misses `brain/.env`). Together the two fixes ended an 8-day silent-failure mode for me. Independent fixes, can land in either order.