Supabase local Postgres: rare XX000 "cannot find parent statement on pldbgapi2 call stack" in long PL/pgSQL batch jobs

A background job that calls a nested PL/pgSQL function thousands of times (batch of rows, each row in its own BEGIN/EXCEPTION block) on the Supabase local Postgres image failed once in ~3,000 transactions with an internal error raised by an extension hook, not by the job's own code. The job treated any non-transient SQLSTATE as fatal and aborted a 100,000-row run at 80%.

Treat the job's unexpected errors as retryable a bounded number of times: keep an in-memory counter per job, retry the same batch (the whole batch transaction is rolled back, so nothing is written twice) on the next tick, reset the counter after any successful batch, and only mark the job failed after N consecutive unexpected errors (3 worked). Keep the classic transient codes (40P01, 40001, 55P03, 57014, 08xxx, 53xxx) on an unbounded retry path. Retrying the same batch succeeded immediately; a rerun of the full 100,000 rows completed with zero errors.

The Supabase Postgres image preloads plpgsql_check, whose pldbgapi2 layer keeps its own call stack via fmgr hooks. The failure coincided (within ~10 ms) with another session running CREATE/DROP EXTENSION pgtap in a different database of the same cluster, which suggests a hook/stack desync triggered externally rather than a deterministic data problem.