The last commit taught the settlement screen to SEE money billed twice. It
still could not do anything about it: the panel described the problem and
then offered "تسجيل باقي القيمة", which bills MORE. The only way to
actually fix the reported account was an admin editing the invoice by
hand, which is how it broke in the first place.

So the screen gets the missing action. `void_duplicate` takes a demand off
the books — reduce an invoice, or cancel it outright — and it is
deliberately not a waiver. A waiver forgives a debt that was real and is
revenue given away; this removes a demand that should never have existed,
so the club is not out of pocket by a piaster and it reports as negative
billing. The cart's third tile flips to "سيُحذف من المطلوب" rather than
showing a minus sign under "سيُفوتَر".

Detecting is only half a tool. An operator standing in front of a parent
needs to know WHICH of six invoices carries the duplicate, and the second
spent working that out is the second the wrong one gets cancelled. So the
wizard matches the excess back to the invoices that could be carrying it,
newest first, and pre-fills the amount: on the reported account it offers
"INV-000593: 5,500 -> 3,000" as one button. The worklist states the
figure on the row, so the excess is visible before anything is opened, and
severity now colours the chips — a double-billing and a missing month read
identically before, which is why the list got worked top-to-bottom.

The guard is the whole value of the thing: an invoice with money collected
against it is never touched. Reducing one below what was paid strands real
money — the payment row saying one thing, its immutable ledger entry
another, which is exactly the damage the old correction wizard used to do.
That money has somewhere to go (move_payment, or credit_wallet) and which
is right is a person's decision, so the action refuses and the panel says
so instead of offering a button. Same refusal for an invoice belonging to
another participant, for raising an amount through a tool named for
lowering it, and for an invoice with more than one line, where reducing
the header cannot say which of two lines was the duplicate.

Verified end to end against the restored tenant, which still carries the
account in its broken state: scanner flags one, screen proposes
INV-000593 5,500 -> 3,000, applying it leaves billed 8,000 of an 8,000
card with 3,000 still owed, and the re-scan comes back clean — the same
correction that had to be made by hand on production, now one click.
364 tests green on SQLite and Postgres.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>