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/REMOTE_AND_SELF_PACED_ARCHITECTURE.md

@@ -51,15 +51,13 @@ this flow specifically — see the Phase 4.1 report for the full run results.
    product/business decision (course commerce, is it free, who's allowed to enroll), not an
    infrastructure gap.
 
-2. **No real student authentication.** A student session is created from a bare `student_id`
-   (`POST /api/login`, no password) — deliberately, since today every `student_id` is issued and
-   controlled by an instructor via the roster, not chosen or known by the public. A genuinely
-   remote/self-paced product where students access their account without an instructor in the
-   loop needs real credentials (email+password, or a magic link) — reusing the same
-   `password_hash`/`scrypt` machinery `instructors` already has (`src/auth/password.js`) would
-   be the natural extension, not a new auth system. **This is the one item on this list that
-   would actually block self-paced delivery today** — everything else already works or is a
-   product decision, not an infrastructure one.
+2. ~~**No real student authentication.**~~ **Closed in Phase 5A.** Students now have real
+   credentials (email+password or login-identifier+password, `password_hash`/`scrypt` reusing
+   `instructors`' exact `src/auth/password.js`), a first-login/reset token flow, and Postgres-
+   backed rate-limited/CSRF-protected sessions on the same `sessions` table instructors use — see
+   `docs/PHASE5A_STUDENT_IDENTITY_REMOTE_CLASSROOM.md`. The old bare-`student_id` `POST
+   /api/login` still works for not-yet-converted pilot rows only; it's rejected (409) the moment
+   an account has real credentials or a pending activation token.
 
 3. **`curriculum_assignments.student_id` is schema-ready but unwired.** The table has supported
    a direct per-student curriculum assignment (independent of any cohort) since Phase 2B
@@ -80,6 +78,6 @@ this flow specifically — see the Phase 4.1 report for the full run results.
 
 No signup flow, no student password/email auth implementation, no per-student curriculum
 assignment route, no payments, no public course catalog, no held/premium scenario content. All
-explicit non-goals per this phase's authorization. This document exists so Phase 5 planning
-starts from an accurate picture of the gap (one real item: student authentication) instead of a
-guess.
+explicit non-goals per this phase's authorization. Student authentication (item 2, above) was
+closed in Phase 5A; the rest remain open, unmodeled by design (YAGNI) until a real product
+reason exists.