Add policy, intake, and payment history to the admin student detail view

The student-administration spec deferred three detail-view sections until
Payments landed. Adds them now: policy-acceptance history (title, version,
context, date), intake answers (label, answer, context), and — gated on
manage_billing — payment history with HST breakdown and receipt numbers.

New Auth\StudentHistory builds the display rows from per-student queries
added to AcceptanceRepository, AnswerRepository, and PaymentRepository;
the Payment model now carries created_at so unpaid rows still have a date.

Closes #69

Co-Authored-By: Claude Fable 5 <[email protected]>

docs/features/student-administration.md

@@ -10,6 +10,11 @@ No new tables. The views are composed from existing data:
 - Students are WordPress users with the `us_student` role (`get_users`, `get_userdata`).
 - Lessons come from `{prefix}us_lessons` (with `{prefix}us_availability` for slot times).
 - Group-class enrolments come from `{prefix}us_group_enrollments`.
+- Policy acceptances come from `{prefix}us_policy_acceptances` (with the policy
+  and version tables for titles/numbers).
+- Intake answers come from `{prefix}us_question_answers` (with `{prefix}us_questions`
+  for labels).
+- Payments come from `{prefix}us_payments`.
 
 ## Admin Interface
 **Students** in wp-admin (`manage_students`, studio admin only):
@@ -22,10 +27,15 @@ No new tables. The views are composed from existing data:
   - **Upcoming lessons** and **Past lessons** — split by the linked availability
     slot's `start_dt`; each shows date/time, offering, instructor, and status.
   - **Group-class enrolments** — active/past, with offering title and status.
-  - *(Later)* policy-acceptance history, intake answers, and payment history once
-    Payments lands.
+  - **Policy acceptances** — every acceptance the student has recorded, newest
+    first: policy title, version, context (account signup / lesson / enrolment),
+    and when it was accepted.
+  - **Intake answers** — every registration-question answer, newest first:
+    question label, answer, and the registration it was given for.
+  - **Payment history** (`manage_billing` only) — every payment, newest first:
+    date, context, method, status, subtotal, HST, total, and receipt number.
 
-Read-only in this iteration; cancel/edit actions are a possible follow-up.
+Read-only in this iteration; cancel/edit actions are a possible follow-up (#70).
 
 ## Capabilities
 - `manage_students` — studio admin (administrators inherit it via the
@@ -38,6 +48,11 @@ Read-only in this iteration; cancel/edit actions are a possible follow-up.
   `Availability\AvailabilityRepository::findById`,
   `Offering\OfferingRepository::findById`,
   `GroupClass\EnrollmentRepository::findByStudent` + `countActiveForStudent`
+- History sections: `Auth\StudentHistory` builds the display rows from
+  `Policy\AcceptanceRepository::findByStudent`,
+  `Registration\AnswerRepository::findByStudent`, and
+  `Payment\PaymentRepository::findByStudent`, resolving policy/version titles and
+  question labels (unit-tested with mocked repositories).
 - Upcoming/past split: `Auth\StudentSchedule::partition()` (pure, unit-tested)
 - The upcoming/past split is extracted into a small pure helper so it is
   unit-testable (the controller itself follows the repo convention of not being
@@ -45,3 +60,7 @@ Read-only in this iteration; cancel/edit actions are a possible follow-up.
 
 ## Tests
 - `tests/Unit/Auth/StudentScheduleTest.php` (the pure upcoming/past split helper)
+- `tests/Unit/Auth/StudentHistoryTest.php` (history display rows + fallbacks)
+- `findByStudent` coverage in `tests/Unit/Policy/AcceptanceRepositoryTest.php`,
+  `tests/Unit/Registration/AnswerRepositoryTest.php`, and
+  `tests/Unit/Payment/PaymentRepositoryTest.php`