Answers the per-transfer cap that applies to a transfer you are about to create,
so you can size the amount (or ask the API to split it, see split on
createBankTransaction) before you send anything.

The cap is not a property of a bank alone: it depends on the sending bank, the
destination bank (same-bank transfers are never capped), whether the transfer
belongs to an online or a deferred payroll, and the LBTR flag. Rather than
reimplementing those four rules — and drifting from them — ask here.

The answer does not depend on the amount, so it is cacheable — but the caller is
part of the key: (caller, sender_id, recipient_id, bank_payroll_id, lbtr). Both
recipient_id and bank_payroll_id are resolved through the calling user's own
visibility, so the same tuple is a 404 for a caller who cannot see them and a cap
for one who can. Cache it private / per-session only — never in a shared or proxy
cache, which would hand the second answer to the first.

It resolves a cap, it does not validate the transfer

This endpoint answers only "how large may one transfer be". It does not run the
validations of createBankTransaction, so a 200 here is not a promise that the
transfer is creatable — in particular for lbtr:

• lbtr: true between two accounts of the same bank answers max_amount: null
  (same-bank is uncapped), but creating it is a 422 "Lbtr cannot create lbtr transaction if the sender and recipient belong to the same bank".
• lbtr: true out of a bank other than Banco de Chile or Santander answers that
  bank's ordinary cap (LBTR does not lift it there), and creating it is a 422 "Lbtr is not yet implemented at bank {bank_id}".

The rest of the create-time rules (recipient approved, description format, budget,
payroll state) are likewise out of scope here; they are listed on the 422 of
createBankTransaction.