Finished what last night shipped as configured-but-manual. Mapped the
Installments module properly this time: cheques for a membership
installment plan live in `installment_cheques`, a table with no status
lifecycle and no connection to the accounting cheque system at all
(negotiable_instruments sits at zero rows) — two insert sites
(ChequeController::storeBatch / store) plus a historical-backfill path
in RetroactiveMembershipService.

The fee cannot be folded into the plan's own total: `total_with_interest`
is recalculated from principal and interest alone
(InstallmentController::recalculate) and both intake paths hard-validate
cheques against it — anything added would be silently erased or reported
as a shortfall. So it bills as its own claim, the same shape as every
other accrual in this system: Dr member receivable / Cr the clearing-fee
revenue account already sitting in the chart from last night
(410540), collected alongside the member's next ordinary payment.

The billing unit is the CHEQUE, not the batch, via a
`clearing_fee_charged` flag added to installment_cheques — which is also
the idempotency key. A plan finished across three cashier visits bills
three times for exactly the cheques each visit added; a retried request
bills nothing twice. The 102 live cheques already on file are marked
charged in the same migration — they were handed over before this
feature existed, and backfilling a charge onto them would invent
something no member agreed to.

Verified against a scratch copy of production: a fresh 3-cheque batch
bills exactly 75.00 across 3 receivables, a replay bills nothing, a
second visit adding 2 more cheques to the same plan bills exactly
50.00, a branch with no fee configured bills nothing and leaves those
cheques correctly unbilled (not stuck), and the historical 102 stay
untouched. Trial balance nets to 0.00.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>