Sustained disconnect-call audit failures in batch_retry_health (v0.41.28.0, Supabase transaction pooler)

Per v0.41.28 guidance

If batch_retry_health shows disconnect calls > 0, file an issue with that data so v0.41.28+ can target the right ownership boundary.

Environment

• gbrain version: 0.41.28.0
• Install method: bun-link (from source clone)
• Database backend: Supabase Postgres (pgvector)
• Connection path: Supabase transaction pooler on port 5432
• GBRAIN_DISABLE_DIRECT_POOL=1 (direct connection disabled; pooler is the only path)
• OS: macOS
• Node/Bun runtime: bun 1.3.14

Doctor output — batch_retry_health

{
  "name": "batch_retry_health",
  "status": "fail",
  "message": "1008 exhausted batch retries in last 24h (worst: extract.links_fs = 1008). Sustained circuit-breaker incident. Fix: check pooler status; consider raising GBRAIN_BULK_MAX_RETRIES or moving to direct-connection. Disconnect-call audit: 12 call(s) in 24h (most recent caller: at disconnect (<home>/gbrain/src/core/postgres-engine.ts:207:7))."
}

• connection check: ok (database reachable)
• stale_locks: ok
• queue_health: ok
• All 1008 exhausted retries are concentrated in extract.links_fs.

Key observation

The disconnect-call audit is naming postgres-engine.ts:207 as the caller — this is internal to gbrain's own PostgreSQL engine module, not an external timeout or network-layer disconnect. The connection check passes, yet the retry circuit-breaker is sustaining 1008 exhausted retries in a single operation class over 24h.

Expected behaviour

Either the retry logic recovers after the disconnect, or the disconnect origin is correctly attributed so the ownership boundary can be addressed.

Steps to reproduce

1. Run on Supabase transaction pooler with GBRAIN_DISABLE_DIRECT_POOL=1.
2. Allow dream cycle to reach the link extraction phase.
3. Observe batch_retry_health via gbrain doctor --json.