Add Cloudflare Access authentication

[imsergiy]

Cloudflare Access already authenticates requests at the edge, but Twenty still requires a separate password login. This change verifies the signed Access JWT, maps its email to an existing member of one configured workspace, and creates a normal Twenty session through the existing login-token flow. Browser page requests start this exchange automatically and return to the requested page.

Unknown users and users outside the configured workspace receive 403. API requests keep their existing authentication behavior.

Validation

• Focused Jest suites: 2 passed, 11 tests passed
• JWT signature, issuer, audience, and email claim validation covered
• Existing secure and local session cookies, callback exclusions, non-page requests, disabled configuration, workspace membership, and return-path validation covered
• Production server image build performed for deployment

Decisions

• Pin Twenty to v2.40.0 — a fixed release makes upgrades deliberate and rollback reproducible; do not use the mutable latest tag.
• Keep Twenty in /home/sergiy/twenty as its own Compose project — this isolates CRM lifecycle and data from taskmachine; do not add unrelated services to the taskmachine stack.
• Publish Twenty only on 127.0.0.1:3020 — the existing Cloudflare Tunnel is the only public path and port 3000 is occupied; do not expose the application on all host interfaces.
• Disable creator-facing telemetry and icon lookups explicitly — set telemetry and analytics off, use console-only errors, disable support chat, and disable Twenty icon requests; do not rely on upstream defaults.
• Use local Docker volumes for Postgres and uploaded files — box1 has sufficient local capacity and the official stack supports this path; do not add external storage or a managed database.
• Upgrade Twenty manually from pinned releases — release review and a verified backup reduce migration risk; do not attach this stateful CRM to an automatic image updater.
• Defer backups at the user's request — the deployment is authorized without backup automation; do not add a backup timer now.
• Persist Redis queue data with AOF — queued work should survive container recreation; do not leave the queue on an ephemeral filesystem.
• Disable automatic marketplace catalog synchronization — the initial CRM does not need background npm catalog requests; app discovery can be enabled later when needed.
• Do not enable Enterprise SSO without a privacy decision — v2.40.0 requires an SSO entitlement and Enterprise validation sends instance metadata, counts, and an administrator email to Twenty independently of the telemetry toggle; leave authentication unchanged rather than introduce this creator contact or a custom authentication layer without agreement.
• Integrate Cloudflare Access inside a narrow Twenty patch — verified JWT-to-login-token exchange reuses Twenty sessions without storing proxy passwords; do not make an external gateway own generated user credentials.
• Map Cloudflare identities only to existing active Twenty members — Cloudflare proves identity while Twenty continues to control CRM membership; do not create users or workspaces from an edge identity.
• Base the maintained patch on the fork's current main branch — GitHub blocks creating a release-tag branch because the available OAuth token cannot write workflow files that differ from the fork; do not deploy an unpushed local-only patch.
• Detect sessions through Twenty's UserSessionCookieService — it handles both secure and local cookie names from the raw header before session middleware runs; reading request.cookies would redirect valid sessions.
• Bind Cloudflare sign-in to one configured workspace ID — direct membership lookup authorizes only the intended workspace even if its discovery mode changes; automatic workspace selection could expose a different membership.
• Carry validated relative return paths through Cloudflare sign-in — users should return to the requested CRM page, while rejecting protocol-relative paths prevents an external redirect.