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]>

docs/features/parent-guardian-accounts.md

@@ -201,19 +201,36 @@ Per child the form collects:
   practice they describe the student (instrument, level, school). The guardian
   answers them on the child's behalf; the answer row's `student_id` is the child.
 
+### What the account holder gives when they are a student
+
+Under `self` and `both` the account holder is a student too, so the **About you**
+panel asks them for exactly the same two things every other student gives: their
+**birth year** (`us_birth_year`, the same meta key and the same
+`normaliseBirthYear()` rule — `GuardianService::setBirthYear()` writes both cases)
+and the **account-scope questions**. Both are stored against their own user id.
+
+The panel sits on the main form, above the students, rather than behind a "Next".
+The questions used to be a second step, which put what the studio needs to know
+about an adult student on a screen they reached only after everything else; now
+one page holds one decision each — who you are registering, about you, about
+them.
+
+`register.js` takes the whole **About you** fieldset out of play under
+`students`, by `disabled` as well as `hidden`: a disabled fieldset is neither
+validated nor submitted, so a `required` field cannot block a form on a control
+nobody can reach. The students block is toggled the same way, and the server
+enforces both rules regardless — which is what makes them hold with JavaScript
+off. The profile screen has no such problem: its forms are always visible, so the
+attribute is static there.
+
 Name and birth year are marked required in the labels the same way a required
-question is, but the signup form **cannot** lean on the browser to enforce them:
-the child blocks are hidden until the parent/guardian box is ticked, and a
-`required` field inside a hidden container makes the form unsubmittable with no
-control the user can reach to fix. `register.js` therefore puts `required` on
-and takes it off along with the block itself (`[data-us-child-required]`), and
-the server checks regardless — which is what makes the rule hold with
-JavaScript off. The profile screen has no such problem: its forms are always
-visible, so the attribute is static there.
+question is; `[data-us-child-required]` keeps the attribute on the child fields
+in step with the block they live in.
 
 Order of operations in `RegistrationPage::handleSubmit()`:
 
-1. Validate the guardian's own fields (email, password, policies).
+1. Validate the account holder's own fields (email, password, policies, and —
+   when they are a student — their birth year and answers).
 2. Validate **every** child block — a missing name, a missing or unusable birth
    year, or a missing required per-child answer fails the whole submission
    **before** any user is created, so a half-registered family is never left
@@ -221,7 +238,8 @@ Order of operations in `RegistrationPage::handleSubmit()`:
    always renders one spare for "add another"; a block with anything at all
    typed into it is kept and reported on, rather than silently discarding what
    the guardian entered.
-3. Create the guardian user.
+3. Create the guardian user, and record `us_guardian_only` and (when they are a
+   student) their birth year against it.
 4. For each child: create the accountless user, link it, record its answers, and
    record the signup policy acceptances **against the child** with
    `accepted_by = <guardian>`.