Phase 1 scaffold: auth for all apps

- Backend: Fastify with two listeners (public + internal), routes, services, DB migration + seed
- client_app: Flutter with BLoC, all auth screens (welcome, display name, register, OTP, force-register)
- mitra_app: Flutter with BLoC, OTP-only login
- control_center: React + Vite, email/password login, mitra/user management, anonymity settings
- Docs: phase1 plan, API contract, client app mockup
- CLAUDE.md and shared memory for all subprojects

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

mitra_app/.claude/memory/MEMORY.md

@@ -0,0 +1,3 @@
+# Memory Index
+
+- [Mitra App Context](context.md) — Flutter, Firebase Auth native, calls /api/mitra/ and /api/shared/ only, requires control center approval

mitra_app/.claude/memory/context.md

@@ -0,0 +1,17 @@
+---
+name: Mitra App Context
+description: Stack, purpose, and API conventions for the Halo Bestie mitra Flutter app
+type: project
+---
+
+Flutter mobile app (iOS + Android) for trained mental health professionals (mitra/partners).
+
+**Stack:** Flutter, Firebase Auth (`firebase_auth` + `google_sign_in`)
+
+**Auth:** Google Sign-In (native), Apple Sign-In (native), Phone OTP — fully native, no WebView. JWT sent as `Authorization: Bearer` on every API call.
+
+**API:** Calls `/api/mitra/` and `/api/shared/` routes only. Never call `/api/client/` or `/internal/`.
+
+**Domain:** Mitra = trained mental health professional. Flow: register + credential upload → await control center approval → set availability → accept sessions → chat with client → receive payout.
+
+**Important:** Mitra accounts require approval from control center before going live. Mitra role must be verified server-side on every relevant request — never rely on client-side role checks.