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/brief/domain/besluit.ts

@@ -0,0 +1,93 @@
+import { Besluit, LetterBlock, LibraryPassage } from './brief';
+
+/**
+ * Guided drafting: given the behandelaar's besluit + chosen redenen, which library
+ * passages belong in the kern. This is the "don't make them a detective" logic —
+ * pure, so it's unit-tested directly and the UI just renders the result.
+ *
+ * A passage is offered when:
+ *  - it has no besluit tag (a shared intro/toelichting, relevant to any besluit), OR
+ *  - its besluit matches AND either it isn't reason-specific, or its reason is ticked.
+ *
+ * Kept in library order (server order = reading order), so an inserted set already
+ * flows as a letter.
+ */
+export function passagesForBesluit(
+  passages: readonly LibraryPassage[],
+  besluit: Besluit,
+  reasons: readonly string[],
+): LibraryPassage[] {
+  return passages.filter((p) => {
+    if (p.sectionKey !== 'kern') return false;
+    if (p.besluit === undefined) return true; // shared, any besluit
+    if (p.besluit !== besluit) return false;
+    if (p.reason === undefined) return true; // besluit-level, not reason-specific
+    return reasons.includes(p.reason);
+  });
+}
+
+/** A selectable reden for a besluit, derived from the reason-specific passages — no
+    separate catalog. `code` drives `passagesForBesluit`; `label` is the checkbox text.
+    ponytail: assumes one passage per reason (true for the seed); dedupes on code if not. */
+export interface Reden {
+  readonly code: string;
+  readonly label: string;
+}
+
+/** Visible assistance for the behandelaar on top of the silent auto-insert: how many kern
+    standaardteksten the current besluit+redenen produced, and whether a reden still needs
+    choosing (the besluit has reason-specific motivering passages but none is ticked). Pure
+    DATA — the component maps it to localized copy. */
+export interface BesluitGuidance {
+  readonly insertedCount: number;
+  readonly needsReason: boolean;
+}
+
+export function besluitGuidance(
+  passages: readonly LibraryPassage[],
+  besluit: Besluit,
+  reasons: readonly string[],
+): BesluitGuidance {
+  return {
+    insertedCount: passagesForBesluit(passages, besluit, reasons).length,
+    needsReason: redenenFor(passages, besluit).length > 0 && reasons.length === 0,
+  };
+}
+
+export function redenenFor(passages: readonly LibraryPassage[], besluit: Besluit): Reden[] {
+  const seen = new Set<string>();
+  const out: Reden[] = [];
+  for (const p of passages) {
+    if (p.sectionKey !== 'kern' || p.besluit !== besluit || p.reason === undefined) continue;
+    if (seen.has(p.reason)) continue;
+    seen.add(p.reason);
+    out.push({ code: p.reason, label: p.label });
+  }
+  return out;
+}
+
+/**
+ * The inverse of `passagesForBesluit`: read the current besluit + redenen back off the
+ * kern's passage blocks (each carries its `sourcePassageId`), so the panel can re-seed
+ * itself on reload/undo without persisting the selection separately. Kern passage blocks
+ * are besluit-derived by construction (the only way passages enter the kern), so this
+ * round-trips: `inferSelection(kern(passagesForBesluit(lib, b, r)), lib) === { b, r }`.
+ * Free-text blocks carry no provenance and are ignored.
+ */
+export function inferSelection(
+  kernBlocks: readonly LetterBlock[],
+  passages: readonly LibraryPassage[],
+): { besluit: Besluit | null; reasons: string[] } {
+  const byId = new Map(passages.map((p) => [p.passageId, p]));
+  let besluit: Besluit | null = null;
+  const reasons: string[] = [];
+  for (const b of kernBlocks) {
+    if (b.type !== 'passage') continue;
+    const source = byId.get(b.sourcePassageId);
+    if (!source) continue;
+    if (source.besluit !== undefined) besluit = source.besluit;
+    if (source.reason !== undefined && !reasons.includes(source.reason))
+      reasons.push(source.reason);
+  }
+  return { besluit, reasons };
+}