The accrual failure had a data cause: nine sa_players rows hold a membership
NUMBER in member_id (897000, 1015, 101) where a row id belongs. The code no
longer breaks on them, but the underlying problem is still real and invisible —
the obligation posts to the ledger while the debt never reaches the member's
account, so nobody chases it.

That is not something an accountant can decide alone; only whoever knows the
player can say which member they are. So it goes on the gaps screen, which is
where the consequence shows up, with the claim count and amount riding on each
one and a link straight to the player's edit form. Where the number matches an
actual membership_number the likely member is offered — two of the nine resolve
that way.

The comparison is numeric on purpose. membership_number is a varchar in
utf8mb4_unicode_ci and the cast of an integer carries the connection collation,
so string-comparing them raises an illegal-mix-of-collations error. It did, and
the catch swallowed it and returned an empty list — a broken query and a clean
bill of health looked identical on screen. That catch now logs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>