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

@@ -0,0 +1,38 @@
+# Frontend Engineer — Memory
+
+This role's own accumulated context: component/pattern conventions in the codebase you work in,
+recurring review feedback, and past implementation judgment calls along with the reasoning
+behind them. Not automatically shared with other roles — see `../../MEMORY.md` on the two-tier
+memory system. Promote anything company-wide to `../../memory/architecture-memory.md` instead of
+leaving it siloed here.
+
+## Recurring review feedback
+
+*None recorded yet.* When the same kind of comment shows up across multiple PRs (a component
+pattern, an accessibility gap, a state-management inconsistency), record it here so it's caught
+before review next time.
+
+## Implementation 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>
+```
+
+## Project-specific context
+
+*None recorded yet.* Notes specific to a project's component library, design conventions, or
+quirks of its existing frontend that aren't obvious from reading the code cold.
+
+## Format for new entries
+
+```
+### YYYY-MM-DD — <short title>
+
+<the observation>
+
+**Why it matters:** <what this changes about how you implement/review going forward>
+```