Let the studio register the students who cannot register themselves

The Book a lesson for a student panel built its picker from the us_student
role but vetted the submission with the book_lesson capability. ChildLoginGate
and RegistrationLoginGate withhold that capability from accounts that keep the
role, so the panel offered every guardian-managed child and every unapproved
signup and then refused them — with a message claiming no student had been
chosen, and a form cleared of all five fields.

Withholding book_lesson stops those accounts registering in their own name. It
was never meant to stop the studio acting for them, which is what the panel is
for, and for a child is the only route to a lesson besides their guardian.

Guard the student role instead, via a new RoleManager::isStudent() shared with
every picker and guard on the staff side so the two cannot drift apart again.
Group enrolment gets the same predicate: addDirect() and grantAccess() vetted
their posted ids not at all, and would enrol an instructor, an administrator,
or an account deleted since the page was drawn — raising a real payment against
them for a priced class.

Keep a refused booking's fields as submitted, reading the form through one
LessonController::submittedBooking() so what gets booked and what is shown
again cannot disagree about a field name. A booking that succeeds still leaves
an empty form, so the next one does not inherit it.

Closes #185

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01XunBYk2sFEc1oL14sUiuBU

docs/features/group-classes.md

@@ -192,6 +192,17 @@ controls beneath it:
    a **pending** invite, the grant is attached to that invite and **no second link is
    sent**. An address that already has an account is treated as **Make available** instead.
 
+Both student-picking controls vet every posted id with `Auth\RoleManager::isStudent()`
+before acting on it — the same predicate the picker is built from, and the same one
+`Booking\AdminBooking` guards a staff booking with. A posted id naming an instructor,
+an administrator, or an account deleted since the page was drawn is skipped rather
+than enrolled, so nothing can put a non-student on a roster or raise a payment
+against one. Being a student is a matter of the **role**, not the `book_lesson`
+capability, so a guardian's child and a signup still awaiting approval are both
+fully enrollable — neither may enrol *themselves*, which is exactly what the studio
+adding them is for. The reported count is what was actually added, so a skipped id
+shows up as a smaller number.
+
 When an email-invited person completes registration, `RegistrationPage` links their new
 account to the grant (`GroupAccessRepository::linkStudentByEmail`), so the invite-only
 class becomes enrollable for them — they choose whether to enrol.