Add platform billing: tiers, dues, payments and invoices

RosterChief charging the clubs, which is a different domain from `shop` (a club
charging its members). Nothing here is club-scoped: these rows reference a Club,
they are not owned by one, and no club user ever sees them.

- Tier + TierPrice. Prices are dated, not keyed by year: a rate change is one row
  with a future active_from, and price_on(day) answers "what was in force then".
  A tier with no price yet returns None, which callers must treat as "cannot
  bill" -- never as free.
- Due: one rolling-year period per club, with a 45-day grace tail. The tier and
  the amount are SNAPSHOTS taken when the period opens. Raise the price and last
  year's period must still say what was actually charged; reading it back through
  the tier would silently rewrite financial history.
- DuePayment: partial payments accumulate. amount_paid is re-summed from the
  payments on every change, never incremented -- an increment drifts the moment a
  payment is deleted, and the drift still looks like money.
- Invoice: PDF via WeasyPrint, rendered on demand from the frozen snapshot. Only
  the number is stored, in one platform-wide series (unlike the shop's per-club
  order numbers), and re-issuing returns the existing one rather than burning a
  number -- a gap in an invoice series is a question you don't want to answer.
  WeasyPrint is imported lazily: it binds to native pango/cairo, and the app, the
  tests and every other page must still run on a machine without them.
- archive_overdue_clubs reports by default and archives only with --commit. That
  asymmetry is deliberate: this switches off paying customers, so a bad clock or a
  cron misconfiguration should cost an email, not a morning of angry clubs. A club
  with auto_archive off is spared entirely.

Renewal continues from the last period end, not from the payment date: a club that
pays two months late has still used those two months.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

billing/services/invoices.py

@@ -0,0 +1,40 @@
+"""Invoice PDFs.
+
+The PDF is rendered on demand from the Due's frozen snapshot (tier, amount, dates), so it
+carries no state of its own beyond the number. Only the number is stored — an accountant
+reconciles against it, so it is allocated once, never recomputed.
+"""
+
+from django.template.loader import render_to_string
+
+from billing.models import Due, Invoice
+from billing.services import BillingError
+
+
+def issue_invoice(due: Due) -> Invoice:
+    """One invoice per due, allocated once. Re-issuing returns the existing one rather than
+    burning a number — a gap in an invoice series is a question you do not want to answer."""
+    invoice, _created = Invoice.objects.get_or_create(due=due)
+
+    return invoice
+
+
+def render_pdf(html: str) -> bytes:
+    """HTML to PDF.
+
+    WeasyPrint is imported here, not at module scope: it binds to native pango/cairo
+    libraries, and a machine without them must still be able to run the app, the tests and
+    every other page — it should only fail when someone actually asks for a PDF, and say why.
+    """
+    try:
+        from weasyprint import HTML
+    except (ImportError, OSError) as error:
+        raise BillingError("PDF rendering needs the native pango/cairo libraries (on macOS: brew install pango).") from error
+
+    return HTML(string=html).write_pdf()
+
+
+def invoice_pdf(invoice: Invoice, base_url: str | None = None) -> bytes:
+    html = render_to_string("billing/invoice.html", {"invoice": invoice, "due": invoice.due, "club": invoice.due.club, "payments": invoice.due.payments.all()})
+
+    return render_pdf(html)