Say "student" and "profile" in the UI, not "child" and "family"

Sweep the translatable strings across the frontend templates, the admin
screens, the editor previews and the block inserter entry. Nothing else
moves: the database columns, request parameters, form field names, CSS
classes, the us_family shortcode and the us-scheduler/family block name are
contracts with existing installs and with post content people have already
saved, so renaming them would break sites for no user-visible gain.

Two strings are reworded rather than swapped, because the direct
substitution reads wrong:

- The students list said "Child of Jane" and now says "Managed by Jane".
  "Student of Jane" would read as a teacher's pupil, which is exactly the
  wrong idea in a music studio.
- A managed account is now "a managed student account" rather than "a
  student account", which would not distinguish it from the account holder.

The guardian feature doc gains a short section on the split, so the next
person to work on it does not read the mismatch as drift and "fix" it.

Closes #144

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

docs/features/parent-guardian-accounts.md

@@ -9,6 +9,19 @@ A guardian may also be a student in their own right — they appear in their own
 "who is this for?" selector alongside their children, so a parent taking lessons
 next to their kids needs only the one account.
 
+## Vocabulary: "child" in the code, "student" in the UI
+
+The interface says **student** and **profile**; the code says **child** and
+**family**. This is deliberate, not drift. Every identifier below — the
+`us_guardian_links` columns, `GuardianService::createChild()`, the `children[]`
+request parameters, the `child_name` form fields, the `us-scheduler/family`
+block name and the `[us_family]` shortcode — is a stable contract with the
+database, saved post content and existing installs, so renaming them would break
+sites for no user-visible gain. Only the strings a person reads were changed.
+
+When adding to this feature, keep the split: internal names follow the
+data model, translatable strings follow the interface.
+
 ## Core Decision: children are accountless WordPress users
 
 Every `student_id` column in `src/Schema.php` (`us_lessons`, `us_payments`,
@@ -159,7 +172,7 @@ child.
 
 ## Managing children
 
-`[us_family]` (block: **Family**) renders the guardian's manage-children screen:
+`[us_family]` (block: **Profile**) renders the guardian's manage-children screen:
 list the children, add one, edit a name/date of birth, remove one.
 
 - **Add** creates another accountless child user and links it. Account-scope
@@ -219,11 +232,11 @@ than being left as a single-student-only path.
 
 ## Admin
 
-- **Students list** gains a **Guardian / Children** column: a child links to its
+- **Students list** gains a **Profile** column: a child links to its
   guardian's detail screen, a guardian lists its children as links. Children are
   listed alongside every other student rather than nested, so nothing about
   finding a student changes.
-- **Student detail** gains a **Family** panel — the guardian (for a child) or
+- **Student detail** gains a **Profile** panel — the guardian (for a child) or
   the children (for a guardian), each a link to the other's screen — and the
   credit balance shown is the **payer's** balance, labelled with whose it is, so
   an admin looking at a child sees the family balance that will actually settle