Consider caching the OID sanity-check status within a transaction/backend #39

Follow-up to #38. General reviewer #2 in that issue's adversarial pass flagged that once every public API function (and the new ddl_command_start trigger) calls the marker-table-gated sanity check, that check runs on every call/statement forever — not just during the post-restore/post-upgrade window — which is a permanent, unnecessary tax on hot, read-only paths once the state is known-clean.

Idea worth exploring (not solved here, deliberately deferred): cache "already verified clean this transaction" (or per-backend/session) so repeat calls within the same transaction/session skip the marker-table lookup entirely. Needs its own design pass: what invalidates the cache (a DDL statement in the same session that could itself introduce staleness? crossing a transaction boundary? nothing, since staleness can only ever be introduced by restore/upgrade/relevant DDL, which the event triggers already see)? Where does the cache live (a session-local GUC, a temp table, a PL/pgSQL session variable via plpgsql.variable_conflict-style pattern, something else)?

Not blocking implementation of #38 — open for whenever it's picked up.