fix(config): global-config PUT can exhaust the DB pool when concurrent saves arm automation (permission check inside the transaction) #1517

Problem

UpdateGlobalConfigAtomic runs its closure inside a transaction that holds a pool connection. When a global-config PUT arms auto-purchase, ladder execution or RI-exchange auto mode, or raises an RI-exchange cap, the closure calls requirePermission, which reads the auth store through the same pool and so needs a second connection. If as many such saves run at once on one instance as the pool has connections (Fargate's default pool is 3, Cloud Run's 6), every one of them waits forever for a connection and the instance stalls. This is the same pattern that #1509 fixed for the service-config PUT, but narrower: it needs several concurrent arming saves. It is already on main and isn't introduced by #1509.

Proposal

Resolve the caller's permissions before opening the transaction, and check them inside the closure against that snapshot, as #1509 does with the commitment options. Nothing inside the transaction should need a second pool connection or a network call.

Acceptance criteria

• A real-Postgres regression test with a small pool and that many concurrent arming saves, which hangs before the fix and finishes quickly after it.
• The grant checks stay exactly as strict as now.

Refs #1488, #1509