docs(phase5a): student identity and remote classroom documentation

- PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md: the full design doc.
- RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md, RUNBOOK_REMOTE_CLASSROOM.md: operational runbooks.
- REMOTE_AND_SELF_PACED_ARCHITECTURE.md: closes the 'no real student authentication' gap this
  doc previously flagged as the one item blocking self-paced delivery.
- ENGINEERING_SOP.md §5 rewritten (was describing a pre-Phase-2A state no longer true of any
  deployed version of this codebase) plus a new §14; roadmap item 3 updated.
- LAB_ARCHITECTURE.md, PRODUCTION_VALIDATION_CHECKLIST.md, README.md, platform/README.md:
  cross-references and a Phase 5A production-validation section.

docs/ENGINEERING_SOP.md

@@ -90,35 +90,34 @@ To add/reorder a stage: edit `rootnode-path.json` directly, referencing existing
 
 ## 5. Student identity — what's built, what isn't
 
-**Built (backend only, as of this doc):**
-- `students` table: `student_id` (`student-NNN`, sequential), `display_name`, `cohort`,
-  `created_at`, `last_active_at`.
-- Login model: **instructor roster, pick-your-name, no password.** `POST /api/roster` adds
-  a student (instructor-only action, currently unauthenticated at the API level — see
-  "not built" below). `GET /api/roster?cohort=X` lists names for a dropdown.
-  `POST /api/login` just validates the id exists and returns it; the frontend is expected to
-  hold onto `student_id` and send it back as an `X-Student-Id` header on every request.
-- `progress` table now keyed on `(student_id, scenario_id)` instead of `scenario_id` alone —
-  each student's completion/attempts/hints are isolated. Verified by smoke test: two students
-  answering the same scenario don't affect each other's state, and pre-migration data was
-  preserved under `student_id = 'unassigned'`.
-- Exam `sessions` now carry `student_id` (set at session start), so exam history and the
-  timer-reset-on-submit logic are correctly scoped per student instead of leaking across
-  whoever's browser hits the API next.
+**Current state (Phase 5A — see `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md` for the
+full design):**
+- `students.student_id` (`student-NNN`, sequential) is still the FK every other table hangs off
+  of and never changes across an account's lifecycle, including conversion.
+- Real credentials: `email` and `login_identifier` (independently optional/unique — email for
+  older/self-paced students, an instructor-assigned login ID for younger ones), `password_hash`
+  reusing `instructors`' exact `scrypt` machinery (`src/auth/password.js`). A student with
+  neither field set is a plain **pilot** account, unchanged since Phase 2A: `POST /api/login
+  { student_id }`, no password, instructor-roster-only.
+- First login/reset is one shared, single-use, hashed, time-limited token mechanism
+  (`students-auth.js`) — instructors never see or set a student's actual password.
+- Sessions are the same Postgres-backed `sessions` table instructors use (opaque, HttpOnly,
+  hashed, revocable, CSRF-protected); login is rate-limited the same Postgres-backed way as
+  instructor login (Phase 4.1), now also applied to students.
+- Per-student `progress`/`scenario_attempts`/exam `sessions` isolation (below) and real
+  concurrent multi-student Lab isolation (Phase 1's Provisioner/k3s-per-student model) were both
+  already in place well before this — Phase 5A only changed how a student proves who they are,
+  not how their data or Labs are isolated.
 
-**Not built yet — do not assume these exist:**
-- **No frontend UI.** No login screen, no name picker, no roster-add form. The API works;
-  nothing calls it yet. This is the next slice.
-- **No auth on `/api/roster` POST.** Anyone who can reach the API can add a "student."
-  Fine for a dev instance, not fine once this is reachable by actual students — needs an
-  instructor-only gate before that happens (ties into the instructor dashboard, roadmap
-  item 3).
-- **No concurrency / isolation.** Exam sessions are still global-single-active
-  (`WHERE status='active' LIMIT 1` — see `server.js`), and there is one shared k3s cluster
-  for the whole instance. Per-student identity ≠ per-student environment. **Multiple students
-  cannot yet use this platform at the same time without stepping on each other.** That's
-  roadmap item 4 (isolation) and it gates real classroom/minors use, same as the plan called
-  out — this SOP is not claiming that gate is cleared.
+**Not built — deliberate non-goals, not gaps (Phase 5A §37):**
+- No public self-registration — accounts are still instructor-created/converted/imported only.
+- No email delivery infrastructure — password reset works via an instructor-issued token today;
+  self-service reset returns a real token only in non-production, by design.
+- No Parent/Guardian portal — the schema doesn't block adding one later, but none exists.
+
+**Historical note, kept for context:** earlier drafts of this section described a pre-Phase-2A
+state (`X-Student-Id` header, unauthenticated roster POST, one shared cluster) that no longer
+reflects any deployed version of this codebase; that content has been superseded by the above.
 
 ## 6. Schema migration pattern
 
@@ -146,9 +145,11 @@ Order agreed 2026-08-17/18. Status as of this doc:
    (§12), student-facing tabs (My Learning/Practice/Assessments/Capstone/Achievements) at
    `frontend/src/platform/`.
 3. Student accounts / persistent progress — **done**, Postgres-authoritative as of Phase 2B
-   (§9), sessions persistent as of Phase 3A (§10). Roster name-picking is still classroom/pilot
-   identification, not strong student auth — documented, not silently glossed over
-   (docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md §7).
+   (§9), sessions persistent as of Phase 3A (§10). Real student credentials (email or
+   login-identifier + password, first-login/reset token flow) closed the remaining "pick your
+   name" gap as of Phase 5A — see §5 above and
+   docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md. Pilot (no-login) accounts still work
+   unchanged for anyone not yet converted.
 4. Instructor dashboard — **done** (§9/§10). Full admin portal at `/admin`: dashboard, cohort
    and student management, classroom Prepare/Destroy Labs, per-instructor accounts with
    owner/admin/instructor roles, audit log.
@@ -332,4 +333,27 @@ Full design: `docs/PHASE4_1_PREPRODUCTION_HARDENING.md`, plus
 - **Known limitation carried forward:** real remote/self-paced delivery needs actual student
   authentication (today's `student_id`-only login relies on instructors controlling who gets a
   valid id) — see `docs/REMOTE_AND_SELF_PACED_ARCHITECTURE.md` for the full accounting of what
-  already works vs. what's genuinely Phase 5 scope.
+  already works vs. what's genuinely Phase 5 scope. **Closed in Phase 5A, below.**
+
+## 14. Student Identity & Remote Classroom (Phase 5A)
+
+Full design: `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`, plus
+`docs/RUNBOOK_STUDENT_ACCOUNT_LIFECYCLE.md` and `docs/RUNBOOK_REMOTE_CLASSROOM.md`.
+
+- **What it is:** two deliverables built on the Phase 4.1 milestone. (A) Real student accounts —
+  email-or-login-identifier + password, reusing `instructors`' exact credential machinery, a
+  single first-login/reset token mechanism, deactivation enforced per-request — replacing pilot
+  "pick your name" identification without touching a single existing pilot student's progress.
+  (B) A remote classroom control center — scheduled/live/ended sessions, derived (not stored)
+  presence via heartbeat, a live instructor dashboard combining real Provisioner Lab state and
+  real academic records, a help-request queue, guidance-only announcements/current-activity, and
+  a generic external meeting-URL field. Explicitly **not** video/voice/chat/shell-takeover —
+  RootNode owns identity and coordination, an external service owns the call.
+- **Tested, not just designed:** `platform/test/e2e-phase5a.js` (21 checks: the two-student RBAC
+  matrix and full password-security checklist, including a real Platform API restart proving
+  rate-limit state survives it) and `infra/scripts/drills/test-phase5a-rehearsal.js` (15 checks:
+  5 pilot students with seeded real history, a live classroom, help requests, **a real
+  mid-rehearsal API restart** proving classroom/session/presence recovery, then converting two
+  students and confirming zero orphaned data) — both against a live `docker-compose.dev.yml`
+  stack, not mocks. The full pre-existing regression suite was re-run given how much shared code
+  this phase touched (`server.js`, `admin-routes.js`, `sessions.js`, `rbac.js`).