Adds SlpModularCms.Api.SlpSoftware and extracts shared CmsHost composition

Unit 1 of the slpsoftware-api feature (FR-1/FR-2/FR-3): a new Client project
in the Clients solution folder, intended to eventually become the deployed
API for test.slpsoftware.nl/slpsoftware.nl, hosting the same four modules as
SlpModularCms.Api plus a future Offerings module.

- Extracts SlpModularCms.Api/Program.cs's hosting-pipeline composition into
  SlpModularCms.Core.Hosting.CmsHost (ConfigureServices/ConfigurePipeline),
  shared by both Client projects so they cannot drift apart
- Moves StaticContentExtensions.cs + WebsitePlaceholder.html from Api into
  Core, since CmsHost cannot live in Api but Core cannot depend on Api
- Adds SlpModularCms.Api.SlpSoftware with its own isolated local dev database
  and dev ports (5286/7223, distinct from Api's and Api.Slave's)
- Adds SlpModularCms.Api.Tests with WebApplicationFactory-based pipeline
  regression tests (security headers, health check, SPA fallback, rate
  limiting), scoped to Api per NFR Design
- Adds a frontend dev:slpsoftware pnpm script mirroring dev:slave
- Fixes GlobalExceptionHandler logging routine 401s (e.g. an expired/missing
  refresh token) as unhandled errors -- pre-existing, unrelated to this
  feature's own scope, found while testing the new instance

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN

aidlc-docs/features/slpsoftware-api/inception/plans/story-generation-plan.md

@@ -0,0 +1,80 @@
+# Story Generation Plan — SlpSoftware Production API
+
+Dit plan beschrijft hoe de user stories en persona's voor deze feature worden opgesteld. Beantwoord eerst de vragen hieronder; na jouw goedkeuring wordt dit plan stap voor stap uitgevoerd.
+
+## Uitvoeringschecklist
+
+- [x] Stap A — Persona's definiëren (`personas.md`): Site Visitor (anonieme bezoeker marketingsite) en CMS Administrator (Administrator-rol, beheert offerings via `/admin`)
+- [x] Stap B — Stories voor de Site Visitor-persona (consumptie van `GET /api/v1/offerings`, incl. leeg-resultaat-scenario)
+- [x] Stap C — Stories voor de CMS Administrator-persona (aanmaken, bewerken, verwijderen, herordenen van offerings, incl. de "featured"-regel)
+- [x] Stap D — Acceptatiecriteria per story toevoegen (Given/When/Then, zie Vraag 2)
+- [x] Stap E — Persona's koppelen aan bijbehorende stories
+- [x] Stap F — Zelfcontrole: elke story voldoet aan INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)
+- [x] Stap G — `stories.md` en `personas.md` opslaan onder `aidlc-docs/features/slpsoftware-api/inception/user-stories/`
+
+## Aanpak-opties voor storyopbouw
+
+- **Persona-based** (aanbevolen): stories gegroepeerd per persona (Site Visitor / CMS Administrator) — sluit direct aan op de twee duidelijk verschillende gebruikersrollen uit requirements.md.
+- **Feature-based**: stories gegroepeerd per capability (lezen, aanmaken, bewerken, verwijderen, herordenen) ongeacht wie de actor is.
+- **Hybride**: epics per persona, met feature-based sub-stories eronder.
+
+---
+
+## Vragen
+
+### Vraag 1 — Storyopbouw
+Welke aanpak voor het groeperen van de stories heeft je voorkeur?
+
+A) Persona-based (aanbevolen) — twee groepen: Site Visitor en CMS Administrator
+B) Feature-based — gegroepeerd per capability (lezen/aanmaken/bewerken/verwijderen/herordenen)
+C) Hybride — epics per persona met feature-based sub-stories
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: a
+
+### Vraag 2 — Detailniveau acceptatiecriteria
+Welk format voor acceptatiecriteria per story?
+
+A) Given/When/Then (aanbevolen — direct bruikbaar als testscenario in latere fases)
+B) Simpele bullet-checklist per story (sneller te lezen, minder gestructureerd)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+### Vraag 3 — "Exactly one featured" regel
+De externe hand-off-doc noemt: "Exactly one package in the list should have `featured: true`" — maar de frontend handhaaft dit niet zelf. Moet de admin-CRUD (bij het aanmaken/bewerken) dit afdwingen?
+
+A) Ja — bij het instellen van `featured` op een offering wordt automatisch de vorige featured-offering ontfeatured (systeem garandeert altijd precies 0 of 1 featured item)
+B) Nee — geen afdwinging; de admin is zelf verantwoordelijk, het systeem staat 0, 1 of meerdere featured offerings toe
+C) Waarschuwen, niet blokkeren — het systeem staat meerdere featured offerings toe maar toont een duidelijke waarschuwing in de admin-UI
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A
+
+### Vraag 4 — Lege lijst op de publieke endpoint
+Wat moet er gebeuren als de admin alle offerings verwijdert, zodat `GET /api/v1/offerings` een lege array `[]` teruggeeft?
+
+A) Toestaan — een lege array is een geldige response; de marketingsite toont dan geen pakket-cards (frontend-verantwoordelijkheid, niet iets wat de API moet voorkomen)
+B) Voorkomen — de admin kan de laatste overgebleven offering niet verwijderen (systeem blokkeert dit met een duidelijke foutmelding)
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]:A
+
+### Vraag 5 — Herordenen (reorder)
+Hoe moet de admin de volgorde van offerings (het `DisplayOrder`-veld uit FR-5) kunnen aanpassen?
+
+A) Drag-and-drop in de lijst-view van de admin-UI
+B) Expliciete "omhoog"/"omlaag"-knoppen per rij
+C) Een numeriek volgorde-veld dat de admin direct invult bij het aanmaken/bewerken
+X) Anders (beschrijf hieronder na de [Answer]:-tag)
+
+[Answer]: A en B
+
+### Vraag 6 — Persona-naam voor de beheerder
+Welke naam/omschrijving past het best bij de admin-persona, gezien de `AdminOnly`-policy (Administrator-rol) uit requirements.md?
+
+A) "CMS Administrator" — generieke, rol-neutrale naam
+B) "Site Owner" — benadrukt dat het (voorlopig) waarschijnlijk de eigenaar zelf is die dit gebruikt
+X) Anders (geef zelf een naam op na de [Answer]:-tag)
+
+[Answer]: CMS Beheerder, als we het nederlands willen houden