✨(all) add organizations, resources, channels, and infra migration (#34)

Add multi-tenant organization model populated from OIDC claims with
org-scoped user discovery, CalDAV principal filtering, and cross-org
isolation at the SabreDAV layer.

Add bookable resource principals (rooms, equipment) with CalDAV
auto-scheduling that handles conflict detection, auto-accept/decline,
and org-scoped booking enforcement. Fixes #14.

Replace CalendarSubscriptionToken with a unified Channel model
supporting CalDAV integration tokens and iCal feed URLs, with
encrypted token storage and role-based access control. Fixes #16.

Migrate task queue from Celery to Dramatiq with async ICS import,
progress tracking, and task status polling endpoint.

Replace nginx with Caddy for both the reverse proxy and frontend
static serving. Switch frontend package manager from yarn/pnpm to
npm and upgrade Node to 24, Next.js to 16, TypeScript to 5.9.

Harden security with fail-closed entitlements, RSVP rate limiting
and token expiry, CalDAV proxy path validation blocking internal
API routes, channel path scope enforcement, and ETag-based
conflict prevention.

Add frontend pages for resource management and integration channel
CRUD, with resource booking in the event modal.

Restructure CalDAV paths to /calendars/users/ and
/calendars/resources/ with nested principal collections in SabreDAV.

docs/entitlements.md

@@ -5,8 +5,10 @@ checking whether a user is allowed to access the application. It
 integrates with the DeployCenter API in production and uses a local
 backend for development.
 
-Unlike La Suite Messages, Calendars only checks `can_access` — there
-is no admin permission sync.
+Calendars checks two entitlements:
+- `can_access`: whether the user can use the app at all
+- `can_admin`: whether the user is an admin of their organization
+  (e.g. can create/delete resources)
 
 ## Architecture
 
@@ -18,7 +20,7 @@ is no admin permission sync.
                │
 ┌──────────────▼──────────────────────────────┐
 │          UserMeSerializer                   │
-│    GET /users/me/ → { can_access: bool }    │
+│  GET /users/me/ → { can_access, can_admin } │
 └──────────────┬──────────────────────────────┘
                │
 ┌──────────────▼──────────────────────────────┐
@@ -97,6 +99,10 @@ is no admin permission sync.
   is denied (returns 403).
 - **Import events is fail-closed**: if the entitlements service is
   unavailable, ICS import is denied (returns 403).
+- **Resource provisioning is fail-closed**: if the entitlements
+  service is unavailable, resource creation/deletion is denied
+  (returns 403). The `can_admin` check follows the same pattern
+  as `can_access` fail-closed checks.
 - The DeployCenter backend falls back to stale cached data when the
   API is unavailable.
 - `EntitlementsUnavailableError` is only raised when the API fails
@@ -157,7 +163,7 @@ class MyBackend(EntitlementsBackend):
     def get_user_entitlements(
         self, user_sub, user_email, user_info=None, force_refresh=False
     ):
-        # Return: {"can_access": bool}
+        # Return: {"can_access": bool, "can_admin": bool, ...}
         # Raise EntitlementsUnavailableError on failure.
         pass
 ```
@@ -175,7 +181,8 @@ Headers: `X-Service-Auth: Bearer {api_key}`
 Query parameters include any configured `oidc_claims` extracted from
 the OIDC user_info response (e.g. `siret`).
 
-Expected response: `{"entitlements": {"can_access": true}}`
+Expected response:
+`{"entitlements": {"can_access": true, "can_admin": false}}`
 
 ## Access control flow