Size DB pool for extension enabled-gate before extension routes carry load

[ToddHebebrand]

Follow-up from PR #2617 (runtime extension platform, Plan 02). Not blocking that PR.

What

createEnabledGate runs on every dispatched extension request and reads installed_extensions through ExtensionStateStore, which escalates via runOutsideDbContext(() => withSystemDbAccessContext(...)).

That escalation is the correct, repo-wide idiom (~20 call sites) and is required — without it the read inherits tenant scope, matches zero rows under the table's FORCE-RLS system-only policy, and the gate fails closed. See PR #2617 for the full trace.

The concern

Escalating exits the ambient context and opens a second pooled connection while the request transaction still holds its first. Every prior use of this idiom is on a cold or background path (OAuth adapter, lifecycle routes, workers). The extension gate is the first hot per-request use.

At meaningful extension-route traffic this doubles connection demand for those requests, and connection exhaustion presents as latency/timeouts across the whole app, not just extensions.

Ask

Before extension routes carry real load:

1. Measure connection-pool headroom under representative extension traffic.
2. Size the pool accordingly, or introduce a short-TTL cache for the gate read if measurement justifies it.

Note a cache trades away the current guarantee that a disable takes effect fleet-wide on the next request — that guarantee is deliberate (it's the emergency shutoff), so any TTL should be small and explicitly chosen, not incidental.

Not a correctness bug

The current behavior is correct and fails closed. This is capacity planning.