docs(phase3a): document production identity architecture

New docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md covers the schema, persistent session
design, instructor accounts, the full RBAC matrix, cohort scoping (including the documented
raw-environment-id simplification), student session hardening (explicitly still
classroom/pilot identification, not production auth), CSRF, rate limiting, audit logging,
the API inventory, a security hardening checklist, test results, known limitations, the
future OIDC path, and production HTTPS/cookie expectations — with an explicit BUILT NOW vs.
FUTURE split.

Updates ENGINEERING_SOP.md (new §9/§10, closing a stale '(§9)' forward-reference that dated
back to Phase 2B), LAB_ARCHITECTURE.md status line, README.md, platform/README.md, and
platform/api/README.md (bootstrap-owner usage, new config vars, no more ADMIN_PASSWORD).

docs/ENGINEERING_SOP.md

@@ -139,17 +139,22 @@ Order agreed 2026-08-17/18. Status as of this doc:
    (`⎈ RootNode Academy Lab — node: k8s-lab`). Upstream KubeKosh attribution left untouched in
    footer/README/LICENSE. Broader "make Real Ops first-class" UI work not started.
 2. RootNode curriculum mode — **backend done** (§4), frontend not started.
-3. Student accounts / persistent progress — **backend done** (§5), frontend not started,
-   no instructor auth yet.
-4. Instructor dashboard — not started.
-5. Per-student isolation — **Phase 1 (platform foundation) + Phase 2A (Gateway + student flow)
-   done**, see §8/§9. Ephemeral per-student Lab environments, Gateway-mediated routing, and a
-   working entry→dashboard→launch→lab→progress flow are implemented and end-to-end tested on a
-   single dev machine, including two simultaneous students with verified cross-student
-   isolation. **Still not cleared for minors** — pilot-grade identity only (no
-   password/SSO), no instructor auth layer, and the production two-VM Proxmox split this
-   depends on doesn't exist yet. See `docs/PHASE2A_GATEWAY_AND_STUDENT_FLOW.md` for exactly
-   what's verified vs. not.
+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).
+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.
+5. Per-student isolation — **Phase 1 + Phase 2A + Phase 2B + Phase 3A done**, see §8/§9/§10.
+   Ephemeral per-student Lab environments, Gateway-mediated routing with persistent
+   server-controlled sessions, a full instructor/admin control plane with real per-person
+   accounts and RBAC, and a working entry→dashboard→launch→lab→progress flow are implemented
+   and end-to-end tested on a single dev machine, including a 3-student cohort classroom
+   workflow and a real Platform API restart mid-session. **Still not cleared for minors** — the
+   production two-VM Proxmox split this depends on doesn't exist yet, and OIDC/SSO is a
+   documented adapter, not a working integration (docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md
+   §16).
 6. Scenarios → teaching modules (incident context/investigation/prevention) — not started.
 7. Capstone/exam engine — not started (placeholder stage only, see §4).
 8. Progressive hint levels — not started.
@@ -157,9 +162,9 @@ Order agreed 2026-08-17/18. Status as of this doc:
 10. CI scenario testing — not started.
 11. Container/build optimization — explicitly deprioritized by design (platform works, not urgent).
 
-Next slice: Phase 2B — instructor dashboard, production auth/SSO, and the identity/progress
-Postgres migration are the biggest remaining items. See
-`docs/PHASE2A_GATEWAY_AND_STUDENT_FLOW.md` §9 for the full Phase 2B list.
+Next slice: production OIDC/SSO, the production two-VM Proxmox deployment, and teaching-module
+scenario content are the biggest remaining items. See
+`docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md` §18 for the full BUILT NOW vs. FUTURE split.
 
 ## 8. Platform Provisioner (Phase 1)
 
@@ -177,7 +182,8 @@ section is just the map.
   auth) or `platform/provisioner/test/run.js` for isolated Provisioner testing.
 - **Where identity lives:** as of Phase 2B, Postgres is authoritative —
   `students`/`cohorts`/`progress`/`scenario_attempts` live in the same `rootnode_platform`
-  database as `environments`, owned by the Platform API's own migrations. See §9.
+  database as `environments`, owned by the Platform API's own migrations. See §9. As of Phase
+  3A, `instructors`/`sessions`/`cohort_instructors`/`audit_events` live there too. See §10.
   `environments.student_id` is still a plain opaque reference, not a real FK — that's a
   deliberate, documented choice (docs/PHASE2B_ADMIN_AND_PLATFORM_DATA.md §2), not an oversight.
 - **Local dev:** `platform/provisioner/docker-compose.dev.yml` runs Postgres + the egress
@@ -189,3 +195,41 @@ section is just the map.
   events). Some properties (idle reaper timing, remote TLS lab-host, reconciliation-on-crash,
   real-image k3s behavior) were validated manually during implementation rather than
   automated — see the Phase 1 final report for what and why.
+
+## 9. Platform API (Phase 2B)
+
+Full design: `docs/PHASE2B_ADMIN_AND_PLATFORM_DATA.md`. Operational reference:
+`platform/api/README.md`.
+
+- **What it is:** `platform/api/` — a lightweight Node/Express service (no k3s, no
+  `--privileged`, no Lab terminal runtime) owning students, cohorts, enrollments, curriculum
+  assignments, progress, scenario attempts, and — as of Phase 3A — instructor accounts,
+  persistent sessions, and the audit log (§10). The sole caller of the Provisioner for both the
+  student launch/reset path and the instructor/admin control plane.
+- **What it is not:** reachable directly by a browser — always through the Gateway
+  (`platform/gateway`), same trust boundary the Provisioner has relative to this service.
+- **Local dev:** part of the same `platform/docker-compose.dev.yml` stack as the Provisioner —
+  no separate compose file.
+- **Test procedure:** `platform/test/e2e-phase2a.js` (student flow) and
+  `platform/test/e2e-phase2b.js` (classroom acceptance workflow) — both need a bootstrapped
+  instructor account as of Phase 3A, see §10.
+
+## 10. Identity and instructor access (Phase 3A)
+
+Full design: `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md`. Operational reference:
+`platform/api/README.md` (bootstrap, config).
+
+- **What it is:** persistent Postgres-backed sessions (student + instructor, survive a Platform
+  API restart), real per-instructor accounts (`owner`/`admin`/`instructor` roles, scrypt
+  password hashing, per-instructor salt), server-enforced RBAC on every `/api/admin/*` route,
+  cohort-scoped access for the plain `instructor` role, CSRF double-submit protection, login
+  rate limiting, and a platform-level `audit_events` log.
+- **What it replaced:** Phase 2B's in-memory session `Map`s (gone on every restart) and the
+  single shared `ADMIN_PASSWORD` env var (no accountability, no roles, no revocation).
+- **Bootstrap:** `node platform/api/bootstrap-owner.js <email> <name> <password>` — the only
+  supported way to create the first instructor account; no manual database editing.
+- **Test procedure:** `platform/test/e2e-phase3a.js` — 21 automated tests covering session
+  persistence (including a real `docker compose restart api`), instructor auth, RBAC, cohort
+  scoping, CSRF, rate limiting, password change, and audit logging.
+- **Known limitations, future OIDC path, production HTTPS expectations:** see
+  `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md` §15–17.