Add admin actions to the student detail view: cancel, withdraw, edit account

Adds the #70 follow-up onto the student detail page: studio admins can now
cancel an upcoming lesson (same path as student cancellation — slot freed,
pending payment voided), withdraw an active group-class enrolment (seat
freed, pending payment voided), and edit the student's display name and
email with validation and uniqueness checks.

Action logic lives in the new Auth\StudentActions (unit-tested with mocked
repositories); the controller routes nonce-protected POSTs to it and shows
success/error notices.

Closes #70

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

docs/features/student-administration.md

@@ -1,9 +1,10 @@
 # Feature: Student Administration
 
 ## Overview
-A read-only studio-admin area to browse students and drill into one student's
-history and upcoming activity — lessons and group-class enrolments — without
-digging through individual records.
+A studio-admin area to browse students, drill into one student's history and
+upcoming activity — lessons and group-class enrolments — and act on their
+behalf: cancel a lesson, withdraw them from a group class, or fix their account
+details.
 
 ## Data Model
 No new tables. The views are composed from existing data:
@@ -35,7 +36,17 @@ No new tables. The views are composed from existing data:
   - **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 (#70).
+### Admin actions (detail view)
+All actions are nonce-protected POSTs handled on the detail page:
+
+- **Edit account** — display name and email. The email must be valid and not in
+  use by another account.
+- **Cancel lesson** — on any non-cancelled upcoming lesson. Uses the same path
+  as student-initiated cancellation: the lesson is marked `cancelled`, the
+  availability slot is freed for rebooking, and a still-pending payment is
+  voided. Paid lessons keep their payment — refunds stay a manual decision (#72).
+- **Withdraw** — on an active group-class enrolment: marked `cancelled` (freeing
+  its capacity seat), with the same pending-payment voiding.
 
 ## Capabilities
 - `manage_students` — studio admin (administrators inherit it via the
@@ -53,6 +64,10 @@ Read-only in this iteration; cancel/edit actions are a possible follow-up (#70).
   `Registration\AnswerRepository::findByStudent`, and
   `Payment\PaymentRepository::findByStudent`, resolving policy/version titles and
   question labels (unit-tested with mocked repositories).
+- Actions: `Auth\StudentActions` — cancel lesson / withdraw enrolment (both
+  refuse records that don't belong to the student, and reuse
+  `Payment\PaymentService::voidPending`) and account updates via
+  `wp_update_user` (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
@@ -61,6 +76,8 @@ Read-only in this iteration; cancel/edit actions are a possible follow-up (#70).
 ## Tests
 - `tests/Unit/Auth/StudentScheduleTest.php` (the pure upcoming/past split helper)
 - `tests/Unit/Auth/StudentHistoryTest.php` (history display rows + fallbacks)
+- `tests/Unit/Auth/StudentActionsTest.php` (cancel/withdraw guards + side
+  effects, account validation)
 - `findByStudent` coverage in `tests/Unit/Policy/AcceptanceRepositoryTest.php`,
   `tests/Unit/Registration/AnswerRepositoryTest.php`, and
   `tests/Unit/Payment/PaymentRepositoryTest.php`