docs(deps): document the dependency-lock convention

Was ambiguous — backend/frontend committed lockfiles, api/gateway/provisioner didn't, with
no stated reason either way. Now explicit: every first-party Node service commits its
package-lock.json, validated with npm ci before each commit that touches it.

docs/ENGINEERING_SOP.md

@@ -233,3 +233,16 @@ Full design: `docs/PHASE3A_IDENTITY_AND_INSTRUCTOR_ACCESS.md`. Operational refer
   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.
+
+## 11. Dependency lock convention
+
+Every first-party Node service commits its `package-lock.json`: `backend/`, `frontend/`,
+`platform/api/`, `platform/gateway/`, `platform/provisioner/`. This wasn't consistently true
+before Phase 3B — `platform/api/`'s lockfile existed locally but was never committed, and
+`platform/gateway/`/`platform/provisioner/` never had one generated at all. Neither was a
+deliberate policy; both were oversights, fixed in Phase 3B (`chore(deps)` commits).
+
+Going forward: after any `npm install` that changes a service's dependencies, the updated
+`package-lock.json` is part of the same commit as the `package.json` change — never left
+untracked, never regenerated-and-ignored. Validate a lockfile actually matches its
+`package.json` with `npm ci` (fails loudly on drift) before committing either.