Require a name and birth year for every student

Both fields are marked in their labels the same way a required registration
question is, and enforced on the server whichever form they arrive from:
GuardianService::createChild() and updateChild() now refuse a blank name or
an unusable birth year, and the signup form checks the same rule up front,
before it creates a single user, so a bad block never leaves a
half-registered family behind. normaliseBirthYear() became public and static
so both paths share one definition of what a usable year is.

The signup form cannot lean on the browser here. Its child blocks are hidden
until the parent/guardian box is ticked, and a `required` field inside a
hidden container makes the whole form unsubmittable with no control the user
can reach to fix — the same trap the guardian's own question panel already
sidesteps by disabling rather than hiding. So register.js puts `required` on
and takes it off along with the block itself, and the server 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.

One behaviour change beyond the requirement: a child block with anything
typed into it is now reported back instead of dropped. Previously any block
without a name was silently discarded, which would now mean losing a birth
year the guardian had filled in. A wholly untouched spare block — the one
the form always renders for "add another" — is still ignored.

Verified the required-toggling in a headless browser: unticked submits,
ticked blocks an empty block, a cloned block inherits the requirement, and
re-unticking leaves nothing behind to block a non-guardian signup.

Closes #148

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

docs/features/parent-guardian-accounts.md

@@ -147,20 +147,36 @@ least one child name.
 
 Per child the form collects:
 - **Name** (required)
-- **Birth year** (optional, `us_birth_year` meta) — a four-digit year between
-  1900 and the current year. Anything else is discarded rather than stored, so
-  a typo cannot leave a nonsense age on the record.
+- **Birth year** (required, `us_birth_year` meta) — a four-digit year between
+  1900 and the current year. `GuardianService::normaliseBirthYear()` is the one
+  definition of what counts, shared by the signup form's up-front validation and
+  by `createChild()`/`updateChild()` themselves, so a bad year is refused rather
+  than quietly discarded and a typo cannot leave a nonsense age on the record.
 - **Every account-scope registration question** (`Registration\Question`,
   `SCOPE_ACCOUNT`) — asked once per child, not once per guardian, because in
   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.
 
+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.
+
 Order of operations in `RegistrationPage::handleSubmit()`:
 
 1. Validate the guardian's own fields (email, password, policies).
-2. Validate **every** child block — a missing child name or a missing required
-   per-child answer fails the whole submission **before** any user is created, so
-   a half-registered family is never left behind.
+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
+   behind. An **entirely empty** block is dropped instead, because the form
+   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.
 4. For each child: create the accountless user, link it, record its answers, and
    record the signup policy acceptances **against the child** with