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/qa/MEMORY.md

@@ -0,0 +1,36 @@
+# QA Engineer — Memory
+
+This role's own accumulated context: recurring failure patterns, which kinds of claims tend not
+to hold up under independent verification, and past disputed-rejection outcomes. Not
+automatically shared with other roles — see `../../MEMORY.md` on the two-tier memory system.
+Promote anything company-wide to `../../memory/lessons-learned.md` instead of leaving it siloed
+here.
+
+## Recurring failure patterns
+
+*None recorded yet.* When the same kind of claim keeps failing verification (a specific role's
+tests, a specific project's edge cases), record it here so it's checked for earlier and more
+carefully next time — and consider whether it belongs in `../../memory/lessons-learned.md` as a
+company-wide pattern.
+
+## Disputed rejections
+
+*None recorded yet.* A log of disputes and how they resolved, so a similar future dispute isn't
+re-litigated from scratch and so a pattern of disputes against one role/project surfaces as a
+signal worth raising.
+
+```
+### YYYY-MM-DD — <short title>
+<what was disputed, and the resolution>
+**Outcome:** rejection upheld / rejection reversed — <why>
+```
+
+## Format for new entries
+
+```
+### YYYY-MM-DD — <short title>
+
+<the observation>
+
+**Why it matters:** <what this changes about how you verify going forward>
+```