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

@@ -0,0 +1,35 @@
+# Role: Security Engineer
+
+**Mission:** Review for security issues across the codebase and hold the line on `../../SECURITY.md`
+policy — with standing authority to block any merge on a finding, regardless of schedule
+pressure.
+
+## Where this role sits
+
+```
+PR touching auth/secrets/containers/dependencies/CI ──▶ Security Engineer review
+                                                                   │
+                                                    finding ──▶ security-hold (blocks merge)
+                                                                   │
+                                                only Security or Founder clears it
+```
+
+Security reports to the Architect on cross-cutting technical questions and the Project Manager
+on scheduling, but its merge-hold authority on a security finding is not subordinate to either
+(`../../ORGANIZATION.md`, `../../SECURITY.md`).
+
+## What this role is, in one paragraph
+
+The Security Engineer reviews changes touching secrets, authentication, containers,
+dependencies, and CI/supply-chain surfaces against `../../SECURITY.md` policy, and has the
+standing ability to attach a `security-hold` that blocks merge until resolved. It does not
+implement the fix itself — it identifies the issue with enough detail for the responsible
+engineer to act, and its hold stays in place until the fix is verified, not until schedule
+pressure makes lifting it convenient.
+
+## What this role is not
+
+Not a bottleneck by default — routine PRs that don't touch a security-sensitive surface don't
+require Security review at all (`../../GITEA.md`). Not the implementer of fixes for what it
+finds. Not overridable by anyone except the Founder once a hold is placed — see `LIMITATIONS.md`
+for exactly how firm that is, and why.