Refactor API and enhance Angular integration

- Removed `ciTargetName` from `nx.json`.
- Updated `package.json` to include new dependencies: `@types/seedrandom`, `fast-check`, `happy-dom`, and `@nestjs/schedule`.
- Modified `pnpm-lock.yaml` to reflect the addition of new packages and their versions.
- Improved project documentation in `PROJECT_CONTEXT.md` to clarify the use of Zod schemas and Angular framework decisions.
- Introduced new Angular components and patterns in the `.agents/skills/frontend-angular` directory, including examples and reference materials for Angular 21+ features.

docs/adr/0008-angular-for-overlay-frontend.md

@@ -0,0 +1,44 @@
+# 0008 — Angular for the overlay frontend
+
+- **Status:** Accepted
+- **Date:** 2026-05-07
+
+## Context and problem statement
+
+`PROJECT_CONTEXT.md` explicitly deferred the overlay framework choice to Stage 2, noting that Vanilla TypeScript + Lit "is likely a better fit" for bundle size and Twitch review simplicity. The overlay app was scaffolded with Angular as a placeholder. A decision is required before building any real overlay components.
+
+## Decision drivers
+
+- **Bundle size.** Twitch reviews extensions manually; a smaller bundle reduces scrutiny risk and load time over arbitrary stream content.
+- **Developer velocity.** Familiarity with a framework dominates iteration speed, especially for a solo build.
+- **Component model fit.** The overlay has three display states and a PubSub subscription — straightforward enough for any framework.
+- **Existing scaffold.** The Angular app already exists in the workspace; switching adds setup cost with no immediate payoff.
+
+## Considered options
+
+1. **Angular.** Full framework; already scaffolded; developer is expert-level.
+2. **Lit.** Web-component library; ~15–20 KB; closer to the platform.
+3. **Vanilla TypeScript (hand-rolled).** Minimal; total control; no dependency; highest maintenance burden for reactivity.
+
+## Decision outcome
+
+**Chosen: Angular.**
+
+The developer is very familiar with Angular and unfamiliar with Lit. Velocity matters more than the marginal bundle-size improvement. Angular's production build with `@angular/build` treeshakes aggressively; the overlay's initial budget is set to 1 MB error / 500 KB warning in `project.json`, which is comfortably achievable. The three overlay states map naturally to standalone Angular components with signals for reactive state.
+
+## Consequences
+
+### Positive
+
+- No framework ramp-up time; patterns (signals, standalone components, `HttpClient`, RxJS) are immediately available.
+- `@angular/build` produces well-optimised production bundles with differential loading and full treeshaking.
+- Existing workspace tooling (`@nx/angular`, ESLint, Vitest via `vitest-angular`) works without additional configuration.
+
+### Negative
+
+- Baseline bundle is larger than Lit or vanilla (~120–200 KB gzipped vs ~15–20 KB). Mitigate with lazy routes if the expanded view grows significantly.
+- If Twitch introduces strict size limits in a future review cycle, migrating is non-trivial.
+
+### Neutral
+
+- Revisit if the production bundle consistently exceeds 400 KB gzipped after Stage 2 is complete. At that point, incremental Lit migration (replacing individual components) is feasible without a full rewrite.

docs/adr/README.md

@@ -24,6 +24,7 @@ We use [MADR](https://adr.github.io/madr/) (Markdown ADR) format. Each record ha
 | [0005](./0005-per-mission-jittered-tick-scheduling.md) | Per-mission jittered tick scheduling | Accepted |
 | [0006](./0006-postgres-plus-redis-data-split.md) | PostgreSQL for durable state, Redis for ephemeral | Accepted |
 | [0007](./0007-devcontainer-with-host-services.md) | Devcontainer with docker-outside-of-docker, services on host | Accepted |
+| [0008](./0008-angular-for-overlay-frontend.md) | Angular for the overlay frontend | Accepted |
 
 ## When to write a new ADR