Demo follow-ups: editable policy name, one-page signup, group classes in upcoming lessons, deletion cleanup

Five items from the latest demo pass:

- A policy's title can be edited from the Policies screen. Only the title
  moves; the slug is what the gates resolve policies by, so a rename can
  never detach a policy from acceptances already recorded against it.
- Signup is one page again. The studio's registration questions move from
  a second step behind "Next" onto the main form, in an "About you" panel
  above the students being added, and that panel also asks an adult
  student for their birth year (the same us_birth_year meta a child's
  uses). register.js disables and hides the whole panel for a pure
  guardian, since the questions describe a student.
- The password is re-scored on submit, not only as it is typed. zxcvbn's
  dictionary arrives after page load, so a password typed straight away
  was never scored at all and the first the student heard of it was the
  server rejecting the whole form.
- Group-class sessions appear alongside lessons wherever upcoming lessons
  are listed: the [us_scheduler] panel (students and instructors) and the
  admin student detail page. GroupClass\SessionSchedule derives them from
  Offering::sessionWindows(), the same derivation the billing scan uses.
  They carry kind = 'group_class' and no Cancel action - a session is one
  date in a term, not a booked slot.
- Deleting a user releases what the account was holding: each upcoming
  lesson is cancelled, its slot freed for rebooking, its pending payment
  voided, and active class enrolments cancelled. Past lessons and paid
  history are left alone.

Tests: composer test (851), composer lint, composer cs all pass.

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

src/Auth/DeletedUserCleanup.php

@@ -0,0 +1,75 @@
+<?php
+declare(strict_types=1);
+
+namespace Unsupervised\Schedular\Auth;
+
+use Unsupervised\Schedular\Availability\AvailabilityRepository;
+use Unsupervised\Schedular\Booking\BookingRepository;
+use Unsupervised\Schedular\Booking\Lesson;
+use Unsupervised\Schedular\GroupClass\Enrollment;
+use Unsupervised\Schedular\GroupClass\EnrollmentRepository;
+use Unsupervised\Schedular\Payment\PaymentService;
+
+/**
+ * Gives back what a deleted account was holding.
+ *
+ * WordPress deletes a user without knowing anything about lessons, so a student
+ * removed from **Users → Delete** used to leave their bookings behind: the
+ * availability slots stayed marked booked and unbookable by anyone else, the
+ * lessons stayed on the instructor's schedule under a name that no longer
+ * resolved, and a group class kept a seat filled by nobody.
+ *
+ * So each upcoming booking is cancelled the same way a real cancellation is —
+ * marked cancelled, its slot released, its still-pending payment voided. Past
+ * lessons are deliberately left alone: they happened, they may have been paid
+ * for, and the payment report has to keep adding up.
+ *
+ * No account credit is issued for a paid lesson, unlike a cancellation the
+ * student asks for. A credit only has value against future billing on the
+ * account it belongs to, and that account is being deleted; a refund owed to
+ * someone who has left is a decision for the studio to make and record, not one
+ * to silently write into a table nobody will read again.
+ */
+class DeletedUserCleanup {
+
+	public function __construct(
+		private BookingRepository $bookings,
+		private AvailabilityRepository $availability,
+		private EnrollmentRepository $enrollments,
+		private PaymentService $payments,
+	) {}
+
+	public function register(): void {
+		// `delete_user` fires before the row goes, which is what lets the lookups
+		// below still find the account's bookings. `wpmu_delete_user` is the
+		// multisite equivalent for a user removed from the network entirely.
+		add_action( 'delete_user', [ $this, 'releaseBookings' ] );
+		add_action( 'wpmu_delete_user', [ $this, 'releaseBookings' ] );
+	}
+
+	/**
+	 * Cancel and release everything the account had booked ahead of it.
+	 */
+	public function releaseBookings( int $userId ): void {
+		if ( $userId <= 0 ) {
+			return;
+		}
+
+		// Upcoming and not already cancelled — the only bookings that are still
+		// holding anything.
+		foreach ( $this->bookings->findUpcomingForStudent( $userId ) as $lesson ) {
+			$this->bookings->updateStatus( (int) $lesson->id, Lesson::STATUS_CANCELLED );
+			$this->availability->release( $lesson->slotId );
+			$this->payments->voidPending( $lesson->paymentId );
+		}
+
+		foreach ( $this->enrollments->findByStudent( $userId ) as $enrollment ) {
+			if ( Enrollment::STATUS_ACTIVE !== $enrollment->status ) {
+				continue;
+			}
+
+			$this->enrollments->updateStatus( (int) $enrollment->id, Enrollment::STATUS_CANCELLED );
+			$this->payments->voidPending( $enrollment->paymentId );
+		}
+	}
+}