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

@@ -0,0 +1,31 @@
+# Success Metrics
+
+How the Backend Engineer role's performance is actually judged.
+
+## Primary metrics
+
+- **QA pass rate on first submission.** A high rate of QA rejections on the same engineer's work
+  signals either rushed verification before marking done, or a gap in understanding acceptance
+  criteria before starting — both worth surfacing, not just individually fixing.
+- **Verification honesty.** Did "tests pass" and "done" actually mean what they claimed, checked
+  against QA's independent verification? This outweighs raw throughput
+  (`../../EMPLOYEE_HANDBOOK.md`).
+- **Review cycle efficiency.** Are review comments addressed substantively on the first response,
+  or does the same feedback need repeating across multiple rounds?
+- **Scope discipline.** Do PRs stay inside their Task's described scope, with adjacent issues
+  flagged separately rather than folded in (`../../CODING_STANDARDS.md`)?
+
+## What does NOT count as success
+
+- High Task-closing volume if QA rejection rates are also high — that's premature closure, not
+  throughput (`../../WORKFLOW.md`).
+- Passing review by avoiding anything architecturally interesting rather than engaging with
+  genuinely hard problems the Task required.
+- Working around a security-hold or QA rejection instead of resolving the actual issue.
+
+## Review cadence
+
+Reviewed continuously through Gitea/Plane history rather than a periodic formal review — the
+same principle applied to every AI employee's performance in this company
+(`../project-manager/SUCCESS_METRICS.md`). Worth explicit revisiting at any retrospective
+touching code quality or QA cycle time.