Let the account holder edit their own profile details

The Profile block is headed "Your profile", but the one person on it you
could not change was yourself: your name, your birth year, and whether you
take lessons yourself were fixed at whatever signup recorded, and correcting
any of them meant asking a studio admin.

A "Your details" section now opens the page, saved through the same
nonce-checked template_redirect post/redirect/get path the child rows use:

- Your name, written to display_name and nickname together, for the reason
  updateChild() does — UserName reads the nickname first, and leaving it
  behind would put the account's email address back on every screen that
  names a person.
- "I take lessons myself", the positive of us_guardian_only. This makes good
  on the claim already in bookableStudents() and the feature doc that a
  guardian-only account can put itself right from the profile page.
- Your birth year, held to the same normaliseBirthYear() rule as every other
  student.

The email is shown but not editable: it is the account's user_login as well
as its address, so changing it stays a studio-side job.

The birth-year field deliberately carries no `required` attribute. It is
asked of a student only, and this page loads no JavaScript, so a
browser-enforced `required` would leave a guardian who books solely for
other people unable to submit the form at all; handleSelf() enforces it
against the checkbox instead. Unticking the box does not clear a stored
birth year — it says who books, not "forget what is on file".

Closes #165

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

docs/features/parent-guardian-accounts.md

@@ -187,7 +187,8 @@ than writing `0`, so "not set" stays the one spelling of "yes, a student".
 
 One guard: a guardian-only account with **nobody linked to it** is still offered
 itself, because an empty picker is no way to book at all. They can put the
-account right from the profile page.
+account right from the profile page — see **Your details** below, where the flag
+is editable as "I take lessons myself".
 
 Per child the form collects:
 - **Name** (required)
@@ -267,9 +268,51 @@ Booking-scope policies are accepted at booking time by whoever is signed in;
 `BookingEndpoint` passes the same `accepted_by` when a guardian books for a
 child.
 
-## Managing children
+## Managing the account
 
-`[us_family]` (block: **Profile**) renders the guardian's manage-children screen:
+### Your details
+
+The profile screen opens with the account holder's own record, because the
+alternative was a page called **Your profile** on which the one person who could
+not be edited was you. The form saves through
+`GuardianService::updateSelf()` and holds:
+
+- **Your name** — `display_name` and `nickname`, written together for the reason
+  `updateChild()` does: `UserName` reads the nickname first, and leaving it
+  behind would put the account's email address back on every screen that names a
+  person.
+- **I take lessons myself** — the positive of `us_guardian_only`, so the form
+  asks the question the way a person answers it and `updateSelf()` is the one
+  place the sense is flipped. This is what makes good on "they can put the
+  account right from the profile page": an account that registered as a pure
+  guardian and later took up lessons — or ticked the wrong radio at signup — can
+  now correct itself instead of asking the studio to.
+- **Your birth year** — `us_birth_year`, the same meta and the same
+  `normaliseBirthYear()` rule every student is held to.
+
+Two decisions worth keeping:
+
+- The birth-year field carries **no `required` attribute**. It is asked of a
+  student only, and the family screen loads no JavaScript, so a browser-enforced
+  `required` would leave a guardian who books solely for other people unable to
+  submit the form at all. `FamilyPage::handleSelf()` enforces it against the
+  checkbox instead, which is where the condition actually lives.
+- Unticking **I take lessons myself** does **not** clear a stored birth year.
+  The box says who books, not "forget what you know about me", and someone who
+  ticks it back on the next visit should find their details as they left them.
+
+The **email** is shown but not editable: it is the account's `user_login` as
+well as its address, so changing it is a studio-side job rather than a
+profile-screen one.
+
+The account-scope questions are not re-asked here, in either direction — the
+child rows do not offer them on edit either, and a studio that needs a newly
+self-declared student's answers asks for them the same way it would for any
+other change of circumstance.
+
+### Managing children
+
+The rest of `[us_family]` (block: **Profile**) is the manage-children screen:
 list the children, add one, edit a name/birth year, remove one.
 
 - **Add** creates another accountless child user and links it. Account-scope
@@ -366,7 +409,8 @@ need — via `GuardianService::contactFor()`.
 - Models: `Unsupervised\Schedular\Guardian\GuardianLink`
 - Repository: `Unsupervised\Schedular\Guardian\GuardianRepository`
 - Service: `Unsupervised\Schedular\Guardian\GuardianService` (child creation,
-  `canActFor()`, `payerFor()`, `contactFor()`, removal rules)
+  `canActFor()`, `payerFor()`, `contactFor()`, removal rules, and the account
+  holder's own record via `accountHolder()`/`updateSelf()`)
 - Login block: `Unsupervised\Schedular\Guardian\ChildLoginGate`
 - Frontend: `Unsupervised\Schedular\Guardian\FamilyPage` (`[us_family]`)
 - Shared question field: `Unsupervised\Schedular\Registration\QuestionField`