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

@@ -0,0 +1,39 @@
+# DevOps Engineer — Memory
+
+This role's own accumulated context: known-flaky CI failure signatures, infrastructure quirks
+discovered in practice, and past triage/pipeline design judgment calls. Not automatically shared
+with other roles — see `../../MEMORY.md` on the two-tier memory system. Promote anything
+company-wide to `../../memory/architecture-memory.md` or `../../memory/lessons-learned.md`
+instead of leaving it siloed here.
+
+## Known-flaky failure signatures
+
+*None recorded yet.* Document the exact failure pattern (error message, timing, which runner)
+once confirmed non-deterministic, before it becomes eligible for the auto-retry policy
+(`../../ACT_RUNNER.md`).
+
+## Infrastructure quirks
+
+*None recorded yet.* Notes about the actual Gitea/ACT Runner deployment (Linux/macOS runner
+behavior, capacity limits, environment-specific gotchas) discovered through operating them, not
+obvious from the policy docs alone.
+
+## Pipeline design judgment calls
+
+*None recorded yet.*
+
+```
+### YYYY-MM-DD — <short title>
+<the call made, and the situation it responded to>
+**Reasoning:** <why this approach, over the alternatives>
+```
+
+## Format for new entries
+
+```
+### YYYY-MM-DD — <short title>
+
+<the observation>
+
+**Why it matters:** <what this changes about how you triage/design going forward>
+```