test(backend): split RuleTests.cs by aggregate, refresh DDD doc (WP-71)

RuleTests.cs held five aggregates' rules as nested classes in one file,
misaligned with Domain/<Aggregate>/ and with the Acceptance/Builders/
folder convention WP-70 started. Split into Domain/<Aggregate>RuleTests.cs
(pure move — same names, same bodies, same count) plus a new
ApplicationRuleTests.cs (the enum invariant moved out of the
WebApplicationFactory-booting ApplicationTests.cs, since it's a pure
Enum.GetNames check with no business needing a web host) and
OrgTemplateRuleTests.cs (RejectDraft had no direct unit test before,
only endpoint coverage).

libs/shared/docs/layers.mdx still taught the pre-WP-67 shape (six
contexts, no apps/libs split, enforcement via ESLint) — updated to the
real monorepo structure and to dependency-cruiser as the actual
enforcement mechanism. Adds specs for registration.policy.ts's
isStatusConsistent (untested; its backend mirror is) and both apps'
auth/domain/session.ts.

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

libs/shared/docs/layers.mdx

@@ -8,30 +8,47 @@ This project is **domain-driven**: the code is organised first by **bounded cont
 (a business capability with its own language) and then by **layer** inside each context,
 with dependencies pointing inward. The Storybook sidebar is laid out to **be** that
 architecture, not just document it: **Foundations** (this curriculum) → **Design System**
-(reusable, domain-free) → **Domein** (the six DDD contexts). If a component lives under a context's `ui/`, it's in Domein; everything else
-in `shared/ui`/`shared/layout` is Design System. See [Atomic design](?path=/docs/foundations-atomic-design--docs)
+(reusable, domain-free) → **Domein** (the app-local DDD contexts). If a component lives
+under a context's `ui/`, it's in Domein; everything else in `libs/shared/ui`/`layout`
+(or `libs/beheer/ui`) is Design System. See [Atomic design](?path=/docs/foundations-atomic-design--docs)
 for the Atoms → Molecules → Organisms → Templates ladder inside Design System.
 
-## Six contexts, one direction
+## Two apps, two shared libraries
+
+This is a **monorepo**: two Angular projects share one backend and one shared library.
 
 ```
-src/app/<context>/<layer>/
+apps/<app>/src/app/<context>/<layer>/   — app-local bounded context
+libs/<lib>/src/<layer>/                 — cross-app library
 ```
 
-Contexts: `shared` (the base layer — depends on nothing), `auth`, `registratie`,
-`herregistratie`, `brief` (letter-composition teaching slice), `showcase` (teaching page,
-sanctioned to read every context — nothing imports it).
+- `apps/ssp` — the Zorgverlener self-service portal. Contexts: `auth`, `registratie`,
+  `herregistratie`, `brief` (letter-composition teaching slice), `showcase` (teaching
+  page, sanctioned to read every context in its own app — nothing imports it).
+- `apps/behandelportal` — the Behandelaar backoffice (ADR-0002). Contexts: `auth`,
+  `behandeling`.
+- `libs/shared` — the design system + kernel + generated API client. No business logic.
+  The base layer: depends on nothing app- or context-specific.
+- `libs/beheer` — the admin/stamdata context, used identically by both apps.
 
-**Dependencies only point inward and in one declared direction between contexts:**
+`auth` is deliberately **not** shared even though today it's near-identical in both
+apps — ADR-0002 models Zorgverlener/Medewerker as different `Principal` variants with
+different login flows, so the two copies are expected to diverge.
+
+**Dependencies only point inward, in one declared direction between contexts:**
 
 ```
-herregistratie → registratie → shared
-auth           → shared
-brief          → shared
+herregistratie → registratie → libs/shared|beheer     (ssp)
+auth           → libs/shared|beheer                    (ssp)
+brief          → libs/shared|beheer                    (ssp)
+behandeling    → libs/shared|beheer                    (behandelportal)
+auth           → libs/shared|beheer                    (behandelportal)
 ```
 
-Never the other way — `registratie` may not import `herregistratie`, and no context but
-`shared` is imported by everyone.
+Never the other way — `registratie` may not import `herregistratie`, no context but
+`libs/shared`/`libs/beheer` is imported by everyone, an app may not import the other
+app's source, and `libs/shared` may not depend on `libs/beheer` (shared stays the base,
+beheer a peer leaf).
 
 ## Five layers, one direction
 
@@ -48,13 +65,20 @@ reach data through an application store or command.
 
 ## This is enforced, not just written down
 
-`eslint.config.mjs` fails the build on every rule above:
+`npm run dep:check` (dependency-cruiser) fails the build on every rule above. One shared
+rule _factory_ (`.dependency-cruiser.base.js`) is instantiated once per app — each app is
+cruised separately against its own `tsconfig.json`, since `apps/ssp` and
+`apps/behandelportal` each declare `@auth/*` pointing at a different physical directory
+and a single merged tsconfig can't resolve both at once:
 
-- `domain/` importing `@angular/*` at all (any context).
-- `shared/` importing a feature context (`@auth/*`, `@registratie/*`, `@herregistratie/*`,
-  `@brief/*`) — the base layer depends on nothing.
+- `domain/` importing `@angular/*` at all (any context, either app).
+- `libs/shared` importing an app feature context, or `libs/beheer` — the base layer
+  depends on nothing.
+- `libs/beheer` importing an app feature context.
+- an app importing the other app's source directly.
 - `registratie/` importing `@herregistratie/*`/`@brief/*`, `auth/`/`brief/` importing a
-  sibling context — the cross-context direction above.
+  sibling context — the cross-context direction above, one `.dependency-cruiser.<app>.js`
+  per app.
 - `contracts/**` importing **anything** — not Angular, not an alias, not even a relative
   path (ADR-0001's wire seam has to stay a pure DTO shape).
 - `ui/**`/`layout/**` importing `*/infrastructure/*` — the anti-corruption boundary
@@ -63,10 +87,15 @@ reach data through an application store or command.
 - The generated `ApiClient` imported as a value outside an `infrastructure/` adapter
   (type-only DTO imports are exempt — they grant no network access).
 
-Two components get a documented exemption from the "nothing reaches across" rule:
-`shared/ui/debug-state` (reads every root store, for the dev-only state panel) and
-`showcase/` (reads every context, for side-by-side teaching pages). Both exemptions live
-next to the rule they break, in `eslint.config.mjs`, so they can't rot silently.
+`showcase` gets a documented exemption from the "nothing reaches across" rule
+(`showcase: null` in `.dependency-cruiser.ssp.js`) — it reads every context in its own
+app, for side-by-side teaching pages. The dev-only state panel (`apps/ssp/src/app/shell/debug-state`)
+reads every root store too, but needs no such exemption: it lives outside any enumerated
+context, so the per-context scoping rule never applies to it in the first place.
+
+`npm run lint` (`eslint.config.mjs`) is a separate gate — mainly the `any`-free rule —
+and no longer carries the import-boundary rules above (moved to dependency-cruiser,
+WP-38/WP-67, so they don't have to be hand-copied per context).
 
 ## The English/Dutch seam