Never drop an enrolled class from upcoming lessons; delete a guardian's children with them; pin the panel's line spacing

Three fixes from testing the branch.

A group class was only listed when its schedule resolved to exact
datetimes, which needs a class time *and* a duration — both optional on
the offering form, and the schedule note exists precisely so a studio can
write "Tuesdays 4:00pm" instead. A class configured that way vanished
from the list, which is the one thing this feature must never do. So
Offering::sessionStarts() splits "when does it meet" from "how long does
it run" (sessionWindows() is that plus the duration, unchanged), and
SessionSchedule degrades instead of disappearing: dated rows with an open
end when there is no duration, and a single row carrying
Offering::scheduleLabel() when there is no time to derive dates from.
Only a class whose last day has passed drops out.

Deleting a guardian now deletes the children linked to them, releasing
each one's lessons and enrolments first. A child account is login-less
and exists only so the guardian has somebody to book for; without the
guardian nobody can reach it, book for it, or be billed for it, so it was
left stranded on the roster still holding slots. A `handled` set makes
the re-entrant delete_user each child deletion fires a no-op, and stops a
circular link recursing.

The upcoming panel never stated its own line-height, so a theme setting
line-height: 0 above it — the usual icon-font reset — was inherited
straight through. Below 1 that produces both reported symptoms at once:
stacked lines overlap, and the status pill's background is shorter than
the text in it. Pinned at the same id-level specificity as the rest.

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

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

docs/features/group-classes.md

@@ -47,9 +47,27 @@ the class meets.
   one row per session however many students are enrolled; enrolments are not
   consulted, because a class still has to be taught if nobody has signed up yet.
 
-A class whose schedule is not fully specified (no time, or no duration) yields no
-windows and so contributes no rows — better absent from a dated list than shown at
-a time nobody chose.
+**A class you are enrolled in must never silently vanish from these lists.** Both
+the class time and the duration are optional on the offering form, and the
+schedule note exists precisely so a studio can write "Tuesdays 4:00pm" rather than
+pin the class to a clock. So the schedule degrades instead of disappearing:
+
+| Class has | What the list gets |
+|---|---|
+| date + time + duration | one dated row per remaining session, with an end time |
+| date + time, no duration | one dated row per remaining session, `end_dt` empty — when it starts is worth showing without guessing when it ends |
+| no class time | **one** row for the class as a whole, sorted by term start (or by "now" once the term is under way), with `schedule` text from `Offering::scheduleLabel()` — the studio's note, else the term dates, else "Schedule to be confirmed" |
+| a term whose last day has passed | nothing |
+
+`schedule` is the tell: non-null means "a class, described in words, not a session
+at a known time", and every renderer shows that text in place of a date and time.
+An undated row's `start_dt` is a **sort key only** — never displayed.
+
+`Offering::sessionStarts()` is the split that makes this work: it needs only the
+date and the time, because knowing *when* a class meets is a separate question
+from knowing how long it runs. `sessionWindows()` is that plus the duration, and
+still returns nothing without one — availability blocking and per-session billing
+need both ends of a window.
 
 Consumers mark these rows `kind = 'group_class'` (`SessionSchedule::KIND`) and
 withhold the per-lesson actions from them: a session is one date in a term, not a

docs/features/student-administration.md

@@ -69,6 +69,19 @@ pending payment voided. Without it the 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 class kept a seat filled by nobody.
 
+**A guardian takes their children with them.** A child account is login-less and
+exists only so the guardian has somebody to book for; without the guardian nobody
+can reach it, book for it, or be billed for it, so leaving it behind leaves an
+unreachable student on the roster holding slots that will never be used. Each
+child's bookings are released on the same terms, the `us_guardians` link row is
+deleted, and the account goes. Deleting a child fires `delete_user` again and
+re-enters the same handler; a `handled` set of user ids makes that a no-op and
+also stops a self-referential or circular link recursing.
+
+(This is a different rule from the family screen's **Remove**, which still refuses
+a child with any lesson or enrolment history — that is a guardian tidying up, not
+an admin deleting an account, and `GuardianService::removeChild()` is unchanged.)
+
 Past lessons are deliberately untouched: 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 either, unlike a cancellation the student asks for — a credit