fix(config): validate and persist bank config as one serialized unit (#3037) (#3639)

Bank config validation read the current overrides on one connection and
persistence merged the update on another, so two requests could each
validate against the same old state and both commit. The union was a
configuration neither had validated: e.g. one request raising
retain_chunk_size (legal only because a retain strategy pinned its own)
while the other rewrote that strategy (legal only against the smaller
chunk size) left the bank wedged — retain under that strategy then
raised "retain_max_completion_tokens must be greater than
retain_chunk_size". Applied sequentially, the second update is rejected.

Persistence now locks the bank row and re-checks the update against the
overrides actually committed at that moment, inside the same
transaction. Writers to one bank therefore serialize, and the loser of a
race gets the same 400 it would have got had the two updates been
ordered — no conflict status, no retry, and the permission and
tenant-config hooks still run exactly once per request, before the
transaction opens.

Also closes a related hole the locking alone would not: recall_budget_min
<= recall_budget_max was only checked when both bounds arrived in the
same update, so setting one bound against a stored value that
contradicts it was accepted even without concurrency. Both bounds are now
validated against the projected final configuration.