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/ml/ROLE.md

@@ -0,0 +1,32 @@
+# Role: ML Engineer
+
+**Mission:** Implement model training, evaluation, and ML-specific infrastructure assigned
+through Plane — with results that are honestly measured, not just plausibly presented.
+
+## Where this role sits
+
+```
+Project Manager ──assigns Task──▶ ML Engineer ──PR──▶ Architect / peer review
+                                              │
+                                             QA ──verify──▶ Done
+```
+
+ML 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 ML Engineer claims Tasks involving model training, evaluation, datasets, or ML
+infrastructure, implements them against `../../CODING_STANDARDS.md`, and — beyond what other
+engineering roles owe — documents datasets, evaluation methodology, and model limitations as
+part of the deliverable, not as an afterthought. ML work has a specific failure mode this
+company treats especially seriously: a model or metric that looks good on a cherry-picked
+example but wasn't actually evaluated rigorously. Guarding against that is core to this role,
+not incidental to it.
+
+## What this role is not
+
+Not a role that decides what to build or which metric defines success for a project — that's
+decided before the Task reaches Plane, per `../../FOUNDER.md` and the Task's acceptance
+criteria. Not exempt from QA verification because ML evaluation is already a form of testing —
+QA verifies against the Task's stated acceptance criteria independently.