Merge pull request 'WS-3 PR-B2a: auth + routing consolidation (single SPA, dual axios, context-aware guards)' (#5) from feat/ws-3-pr-b2a-auth-routing-consolidation into main

Reviewed-on: #5

dev-docs/BACKLOG.md

@@ -823,6 +823,38 @@ introduceert is het natuurlijke moment.
 
 ---
 
+### TECH-PIVOT-ROLES-MULTI — Multi-role per (user, organisation) pivot
+
+**Aanleiding:** WS-3 PR-B2a maakt context-aware routing op
+`me.contexts.available` en `me.organisations[].roles`. Het pivot-veld
+`organisation_user.role` is vandaag een single string (één rol per user
+per org). De resource emit `roles` als 1-element array zodat het
+frontend-contract forward-compatible is, maar het schema ondersteunt
+nog niet meerdere rollen per relatie.
+**Wat:** Architectuur-discussie + design-document, niet een directe
+schema-uitbreiding. Te beantwoorden vragen voordat dit gepland wordt:
+
+- Spatie-permission-integratie: blijft `organisation_user.role`
+  een free-form string of komt het onder `model_has_roles` met
+  team-id = organisation_id? Spatie's "teams" feature is bedoeld voor
+  precies dit scenario.
+- Multi-role-precedence: als een user `org_admin` ÉN `event_manager` is
+  binnen dezelfde organisatie, hoe resolven policies? Hoogste
+  permissie-set? Meest restrictieve? Expliciete merge?
+- Migratie-pad: bestaande pivot-rijen (single string) → array of
+  pivot-tabel naar `model_has_roles`? Backfill-strategie?
+- Frontend impact: `organisations[].role` (scalar) blijft voorlopig
+  staan voor backward-compatibility. Wanneer mag dat veld weg?
+
+**Prioriteit:** Laag — geen blocker voor B2a, B2b of de 4 kern-workflows.
+Pas oppakken wanneer een concrete use case multi-role per (user, org)
+vereist (denkbaar: festival waarbij organizer ook als crew werkt).
+**Belangrijk:** dit is GEEN simpel "voeg een kolom toe" werk. Pak het
+niet op als drive-by tijdens een ander ticket; het verdient een eigen
+ARCH-discussie en RFC.
+
+---
+
 ### ~~TECH-02 — scopeForFestival helper op Event model~~ ✅ OPGELOST
 
 ---