feat(WP-67): merge behandelportal into this repo as a monorepo

Restructures into apps/ssp + apps/behandelportal (two Angular projects)
plus libs/shared + libs/beheer (cross-app libraries), replacing WP-61's
separate sibling repo. That split had already produced real drift: a
hand-vendored copy of the backend's OpenAPI doc, a shared/ui+layout tree
forked and silently diverging (7 files), and beheer + the styles.scss
token bridge duplicated byte-for-byte across both repos.

- git mv the SSP's src/app/* into apps/ssp/; fold shared/, beheer/,
  environments/, the Storybook docs/*.mdx, and styles.scss into
  libs/shared + libs/beheer (all confirmed identical between the two
  repos before merging). auth stays deliberately duplicated per
  ADR-0002 (actor-specific, expected to diverge) - amended there.
- One generated API client (libs/shared), no more vendored swagger.json.
- .dependency-cruiser split into a base factory + one config per app,
  and Storybook into .storybook-ssp/.storybook-behandelportal - both
  forced by the @auth/* alias resolving to different directories per app.
- SiteHeaderComponent/ShellComponent gained HEADER_NAV_ITEMS/
  HEADER_ADMIN_LINKS/DEBUG_PANEL injection tokens so each app supplies
  its own nav/admin-links/dev-panel instead of one being hardcoded.
- CLAUDE.md, ARCHITECTURE.md, dependencies.md, and ADR-0002 updated;
  WP-67 backlog entry documents the full decision trail.

npm run ci green (lint, dep:check x2, 360 tests across ssp/
behandelportal/shared/beheer, both localized builds, backend tests,
snippet + api-client drift); both dev servers, both Storybook
instances, and docker compose verified working.

The old sibling repo (/home/eho/repos/behandelportal) is left
untouched, not deleted.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

apps/ssp/src/app/registratie/domain/aanvraag.ts

@@ -0,0 +1,40 @@
+/**
+ * An application (aanvraag) as the frontend sees it — the parsed, domain-side view
+ * of the backend-owned aggregate (see backend ApplicationStore + PRD 0001). Pure
+ * types, no Angular. Lives in `registratie` because the dashboard (here) is the
+ * consumer and the downstream wizards (`herregistratie → registratie`) produce them.
+ *
+ * The status is a discriminated union so illegal states are unrepresentable — same
+ * reflex as RemoteData. The server computes which tag applies (auto-approval on
+ * read); the FE renders it, it does not recompute the lifecycle.
+ */
+export type AanvraagType = 'registratie' | 'herregistratie' | 'intake';
+
+// Ingediend/MeerInfoGevraagd (ADR-0002/WP-63) are widened into the union so the parse
+// boundary + renderers are ready, but no backend path emits them yet — that's WP-65's
+// behandelaar-facing transition endpoint.
+export type AanvraagStatus =
+  | { tag: 'Concept'; stepIndex: number; stepCount: number }
+  | { tag: 'Ingediend'; referentie: string }
+  | { tag: 'InBehandeling'; referentie: string; manual: boolean } // manual=true → "wordt handmatig beoordeeld"
+  | { tag: 'MeerInfoGevraagd'; referentie: string; reden: string }
+  | { tag: 'Goedgekeurd'; referentie: string }
+  | { tag: 'Afgewezen'; referentie: string; reden: string };
+
+export interface Aanvraag {
+  id: string;
+  type: AanvraagType;
+  status: AanvraagStatus;
+  documentIds: string[];
+  createdAt: string;
+  updatedAt: string;
+  submittedAt?: string;
+  /** The case owner (a BSN). Only populated by the admin cross-owner list (WP-36);
+      the user's own list leaves it undefined. */
+  owner?: string;
+}
+
+/** Detail adds the opaque wizard snapshot used to resume a Concept. */
+export interface AanvraagDetail extends Aanvraag {
+  draft: unknown;
+}