Removes the "this module needs code" category rather than labelling it.

Most unbilled money in the ERP has one shape: a module writes a priced row into
its own table and never tells accounting. Wiring each module by hand means a
developer for every revenue path, forever — which is what I handed over last
time instead of solving it.

A billing source declares that shape as data: which table holds the money, which
column is the amount, which rows are still outstanding, who owes it, and how it
posts. One screen then lists every outstanding charge across every source and
collects it through PaymentService — the same funnel a member payment uses, so
it gets a receipt, treasury custody and a journal entry.

Seeded and working immediately: hourly court bookings, sports subscriptions,
lockers, facility reservations, private matches, rental invoices, annual member
subscriptions.

Edge cases handled deliberately:

- No free-text SQL anywhere. Filters are structured (column / operator / value)
  rendered into prepared statements; a settings screen that accepted a WHERE
  clause would be an injection hole. Identifiers are matched against
  information_schema and a strict pattern before interpolation.
- Every source is re-validated on save AND before every listing, because a
  migration can drop a column underneath a source that was fine yesterday. An
  invalid source is shown as broken instead of silently returning nothing.
- The amount is re-read from the source row at collection time, never trusted
  from the form, so a stale list or a tampered field cannot set the charge.
- Double-collection is blocked by our own billing_source_collections table
  rather than the module's paid flag — some sources have no write-back column at
  all, and a module can overwrite its own flag. The check is repeated at collect
  time to cover the gap between listing and click.
- Partial collection only where the source allows it, never above the row total.
- A player is not a member: a member_id that members does not have is dropped
  rather than tripping the payment foreign key.
- Write-back is best-effort and isolated — a missing column must not undo a real
  payment, so the failure is logged and the receipt stands.
- Zero and negative rows are excluded; an empty IN () renders as a false
  predicate rather than a syntax error.
- Payer names resolve in two queries, not two per row.
- A source with collections against it deactivates instead of deleting, because
  those rows are the audit trail for real money.

Permission keys were read off role_permissions rather than assumed —
payment.create does not exist in this install.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>