Phase_107_002 has never run. Its first INSERT wrote to chart_of_accounts.notes,
a column that does not exist, so the migration threw and MigrationRunner swallowed
it — leaving 3,032,258 EGP of member advances sitting in revenue this whole time.
Writing to description_ar instead lets it complete.

That exposed a second problem the original migration would have caused. It
deactivates 410503/504/505, but payment:down_payment carries an active posting
rule crediting 410503. Deactivating the account without moving the rule means
every future down payment records a receipt and posts no journal entry, because
JournalService refuses an inactive account — quietly worse than the overstatement
being fixed. The rule now moves to the matching contract-liability account, which
is where a down payment belonged anyway: it is an advance from the moment it is
collected, and only becomes revenue as the service is delivered. Otherwise the
account being emptied would just refill.

Also seeds the four bank accounts the chart already names as the club's current
accounts. bank_accounts was empty, which is why the cash chain's deposit step
had nothing to resolve and reported red. Account numbers are deliberate
placeholders reading "رقم الحساب غير محدد" — a seed has no business inventing an
IBAN that could reach a printed deposit slip — and the seed never overwrites a
row someone has already filled in.

And drops POST /waivers/{id}/pay: WaiverController::pay() does not exist, so the
route was a guaranteed 500. Leftover from a direct-payment design that
send-to-cashier replaced; nothing posts to it.

Verified on a full 369-table production clone: balances move (410503/504/505 -> 0,
deactivated; 23081119/20/21 created), entry balances Dr=Cr=3,032,258.00, re-runs
post nothing, down payments still post clean, no active rule anywhere resolves to
a dead or header account, all four chains green, trial balance diff 0.00.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>