Admin maintenance over one subaccount. It first runs the same mask pass
as POST /bank-accounts/link-enrolled-cards, then each action the
request asks for. The actions create cards on the cards platform or
rewrite stored rows, so this route needs banking:admin, while the
mask pass alone stays on link-enrolled-cards at banking:write.
The caller's account comes from its token: it can run maintenance on
any subaccount of its own account, and a subaccount of another account
simply matches nothing (an empty result, not a 403).

Three optional actions, each off by default:

• mint: true runs the completion-time mint pass over the subaccount's
  credit bank accounts that a completed link left without a card (the
  same-last-4 American Express case), so each gains a bank-feed card.
  Idempotent: an account that already holds a minted card is skipped.
• backfillJunctionLast4: true fills, for the subaccount's card links,
  the last 4 each link answers to where it is still unknown, from the
  cards directory. Idempotent.
• createCardholderCards: true runs, now and for this subaccount only,
  what a scheduled job does every 30 minutes: it gives each cardholder
  behind a pooled American Express billing account (a supplementary
  card that is not its own Plaid account) a bank-feed card of their own,
  with the cardholder's name, so their transactions can be emitted on
  that card. It does nothing unless Astrada has switched the feature on
  for the subaccount; the switches are set by Astrada only, from inside
  the platform, and no request can set them. Idempotent: a cardholder
  who already has a card is never given another.

The actions run in the order above, after the mask pass. If the cards
directory cannot be read, the mask pass links nothing and still returns
201; each action then reads the directory again on its own and says
so in its result (directoryUnavailable), or, for mint with accounts
to screen, fails rather than mint unscreened. Any step that fails
returns 400 and runs nothing after it (steps before it have done
their work, and every step is idempotent, so the request can simply be
repeated). Emits no webhook from banking; a card created here produces
the cards platform's usual card-subscription events.