Add weekly and monthly scheduled billing for offerings

Offerings can now bill weekly (a pending payment 24h before each lesson)
or monthly (one payment on the 1st for that month's lessons), alongside
one-time and full-term. Applies to both private lessons and group classes.

- Offering: new `weekly`/`monthly` billing modes + `isScheduledBilling()`
- Booking/enrolment defer payment for scheduled modes; a single lesson
  booked after its due date has passed (e.g. an add-on in an already-billed
  month) is charged at booking instead
- ScheduledBillingRunner: daily WP-Cron scan generates due payments across
  four cases (private/group × weekly/monthly), deduped via lesson.payment_id
  and payments.period_key
- PaymentDueMailer: one consolidated itemised email per student per scan
- Notice batch: payments emailed together share a reference; the admin
  Payments queue groups them with a lump-sum total for e-transfer reconciliation
- Cancellation never voids a scheduled payment (Payment::isScheduled())
- Schema: us_payments gains due_date, period_key, notice_batch; USC_VERSION 1.2.0

composer test, composer lint, composer cs all pass.

Co-Authored-By: Claude Opus 4.8 <[email protected]>

docs/features/payments.md

@@ -88,6 +88,9 @@ After booking, the destination on a payment can be corrected per booking:
 | `status`                   | VARCHAR(20)      | `pending` / `paid` / `failed` / `refunded`            |
 | `tax_rate`                 | DECIMAL(5,2)     | HST rate % frozen at booking; editable until paid     |
 | `tax_amount`               | DECIMAL(10,2)    | Computed tax in dollars (`amount × tax_rate / 100`)   |
+| `due_date`                 | DATE             | When a *scheduled* payment is due; NULL = due at registration (`Payment::isScheduled()`) |
+| `period_key`               | VARCHAR(20)      | Scheduled-billing dedup key: session date (weekly) or `YYYY-MM` (monthly); NULL otherwise |
+| `notice_batch`             | VARCHAR(32)      | Shared reference for the payments one due-notice email covers, so a lump-sum e-transfer reconciles to them; NULL otherwise |
 | `etransfer_email`          | VARCHAR(191)     | Frozen e-transfer destination; editable until confirmed |
 | `stripe_payment_intent_id` | VARCHAR(255)     | Stripe PaymentIntent id; NULL for e-transfer / comp   |
 | `receipt_number`           | VARCHAR(50)      | Sequential receipt id; set when `paid`                |
@@ -102,6 +105,19 @@ After booking, the destination on a payment can be corrected per booking:
 4. On transition to `paid`, `ReceiptMailer` assigns a `receipt_number`, emails the student a receipt, and stamps `receipt_sent_at`.
 5. For an e-transfer, the studio admin later calls `PATCH /payments/{id}` to mark it `paid`, which triggers the same confirmation + receipt.
 
+## Scheduled Billing (weekly / monthly)
+`weekly` and `monthly` offerings are **not** charged at registration. The booking /
+enrolment succeeds with `payment: null`; the lesson is confirmed (or the enrolment stays
+active) immediately, and payments are generated later by the daily
+`us_generate_due_payments` cron scan (`Payment\ScheduledBillingRunner`). Each generated
+payment carries a `due_date` and `period_key`, flows through the same
+`PaymentService::createForRegistration` (so HST, method resolution, e-transfer freezing
+and comp auto-pay are identical), and the student is emailed one consolidated itemised
+notice per scan (`Payment\PaymentDueMailer`). Because these payments are scheduled,
+`PaymentService::voidPending` never voids them — cancelling one lesson leaves a shared
+monthly charge (and every other lesson it covers) untouched, and never rebills. Full
+model, dedup, and the four generation cases are documented in `scheduled-billing.md`.
+
 ## REST API
 | Method  | Endpoint                                    | Permission                  |
 |---------|---------------------------------------------|-----------------------------|