feat(backend): implement phases 0-6 (auth, kc, wahl, files, chat, sync)

Full NestJS backend for the KC-App platform:
- auth: Authentik OIDC resource-server strategy + guest invite-code JWT
  login, plus TokenVerificationService for the WS handshake path
- kc: Leitungsteam-only KC (event) creation/listing
- wahl: Wahl/Workshop admin, Force-Zuteilung overrides, ZuteilungService
  (port of the WP plugin's kc_run_zuteilung), CSV export
- files: LT-only upload with visibility tiers; list/download filtered by
  caller tier; StorageProvider abstraction (WebDAV/Nextcloud default, S3)
- chat: Gemeinde group / DM / LT-wide / broadcast channels; REST + raw ws
  gateway sharing ChatService access rules
- sync: append-only SyncLogEntry replication log + local<->cloud
  push/pull scheduler, shared-secret guarded
- common: Role enum, @Roles decorator, KC-scoped RolesGuard (LT global)
- serves client/web/ interim static web client under / (API under /api)

Typecheck, nest build and boot test pass; needs real Postgres/Authentik/
Nextcloud to run end to end.

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

README.md

@@ -8,19 +8,54 @@ for the full architecture and phased roadmap.
 ## Structure
 
 - `backend/` — NestJS API (Prisma/PostgreSQL, Authentik OIDC as resource
-  server, guest/Konfi local accounts, roles/permissions foundation). See
-  [backend/README.md](backend/README.md) for setup.
-- `client/` — planned Flutter app (mobile + web + desktop), not yet
-  scaffolded (Flutter is not installed in this environment).
+  server, guest/Konfi local accounts, roles/permissions foundation, file
+  sharing, chat, local/cloud sync). See [backend/README.md](backend/README.md)
+  for setup. Also serves the web client (see below) directly, so it's the
+  single entry point for the web experience.
+- `client/web/` — minimal dependency-free HTML/CSS/JS placeholder web
+  client (guest join, Wahl submission, file list, chat) exercising the real
+  API, served by the backend at `/`. Will be replaced by the Flutter web
+  build once Flutter is available.
+- `client/` (mobile/desktop) — planned Flutter app, not yet scaffolded
+  (Flutter is not installed in this environment).
 
 ## Status
 
 Phase 0/1 foundation implemented: monorepo skeleton, Prisma data model (Kc,
 Gemeinde, User, Membership, GuestAccount, Wahl/Workshop/Teilnehmer/Zuteilung,
 File, Chat), Authentik JWT resource-server strategy, guest invite-code login,
-Role-based guard scoped per KC. Backend builds and boots cleanly
-(`npm run build`, `node dist/main.js`) but requires a real PostgreSQL
-database and Authentik instance (see `backend/.env.example`) to run end to
-end. Remaining phases (Wahl-Engine, Dateifreigabe, Chat realtime, Lokal/Cloud
-Sync, Flutter clients) are not yet implemented.
+Role-based guard scoped per KC.
+
+Phase 2 (Workshop-Wahl engine) implemented: Wahl/Workshop administration,
+guest Teilnehmer submission, Force-Zuteilung overrides, and the assignment
+algorithm ported from the WP plugin's `kc_run_zuteilung` (force-assignments →
+wish rounds 1-3 → random fill → consolidation of underfilled workshops),
+plus CSV export.
+
+Phase 3 (Dateifreigabe) implemented: Leitungsteam-only upload tagged with a
+visibility tier (alle / alle außer Konfis / nur LT), list/download for
+Authentik or guest callers filtered by their allowed tiers, storage behind a
+provider abstraction defaulting to Nextcloud/WebDAV (S3-compatible storage
+as an alternative via `STORAGE_PROVIDER=s3`).
+
+Phase 5 (Kommunikation) implemented: Gemeinde-Gruppenchat, 1:1-DMs, LT-
+kanalübergreifende Kanäle, Broadcast (read-only für Konfis); channel/history
+via REST, real-time send/receive via a raw WebSocket gateway authenticated
+with the same Authentik/guest tokens as the REST API.
+
+Phase 6 (Hybrid Lokal/Cloud-Server & Sync) implemented: an append-only
+replication log (`SyncLogEntry`) captured by every feature service after its
+writes; the local (on-site) server periodically pushes/pulls against the
+cloud server's `/sync/ingest` + `/sync/export` endpoints (shared-secret
+authenticated, not user auth). No conflict resolution needed by design - the
+local server is the sole source of truth while an event is live.
+
+The backend now also serves the web client directly (static files from
+`client/web/`, API under `/api`), so the same process is the single entry
+point for the web experience.
+
+Backend builds and boots cleanly (`npm run build`, `node dist/main.js`) but
+requires a real PostgreSQL database, Authentik instance, and Nextcloud/S3
+credentials (see `backend/.env.example`) to run end to end. Remaining: the
+Flutter clients (mobile/desktop; web has an interim plain-HTML client).