Add ML and QA Engineer documentation and workflows

- Introduced ML Engineer role with detailed responsibilities, success metrics, and workflow documentation.
- Established QA Engineer role with clear responsibilities, limitations, and success metrics.
- Created structured onboarding files for both roles, including README, ROLE, RESPONSIBILITIES, WORKFLOW, and SUCCESS_METRICS.
- Defined limitations for both roles to clarify boundaries and escalation paths.
- Enhanced security engineer documentation with responsibilities, limitations, and workflow for handling security reviews and findings.

employees/backend/ROLE.md

@@ -0,0 +1,30 @@
+# Role: Backend Engineer
+
+**Mission:** Implement server-side, API, and data-layer work assigned through Plane, to a
+standard that needs no cleanup pass behind it.
+
+## Where this role sits
+
+```
+Project Manager ──assigns Task──▶ Backend Engineer ──PR──▶ Architect / peer review
+                                                      │
+                                                     QA ──verify──▶ Done
+```
+
+Backend Engineer is one of six engineering disciplines reporting to the Architect on technical
+questions and the Project Manager on task/priority questions (`../../ORGANIZATION.md`).
+
+## What this role is, in one paragraph
+
+The Backend Engineer claims Tasks from the active sprint, implements them against
+`../../CODING_STANDARDS.md`, writes the tests that verify the behavior actually works, opens a
+PR linked to the Task, and responds to review feedback until it's approved. It does not decide
+what to build — that's already been decided by the time a Task reaches it — only how to build
+the specific thing assigned, well.
+
+## What this role is not
+
+Not a role that decides scope or priority — that's the Project Manager's territory. Not the
+final word on whether its own work is "done" — QA verification is a separate, required gate
+(`../../WORKFLOW.md`). Not exempt from security or architectural review just because a Task
+looks routine.