Mobile app — evaluate Fermion branded app vs Expo build

Why / Context

Learner mobile expectations in India-first ed-tech are high (offline video, push). Two candidate paths: Fermion's $199 one-time branded Android/iOS app (offline DRM downloads, push, analytics — but renders Fermion's LMS surface, not ours) vs an Expo React Native app consuming our platform (full product fidelity: cart, projects, portfolio — much higher cost). This issue is the structured evaluation + the chosen build.

Schema already in place — NO migration required

• DeviceToken (push), NotificationPreference channels
• All learner surfaces are server-actions/route-handlers — an RN client would need a thin API layer decision (documented below)

Implementation plan

1. Evaluation spike (2 weeks, decision doc): Fermion branded app trial — what surfaces does it cover (video consumption, live classes, code labs?) vs our differentiated flows (universal cart, project workspace, mentor reviews, portfolio) which it cannot; pricing beyond $199 (per-store fees, update cadence); brand control.
2. Decision matrix: if >70% of mobile usage is content consumption → Fermion app as interim consumption app + mobile-web for the rest; else Expo build.
3. Path A (Fermion app): provision developer accounts, brand assets, map our catalog→Fermion entities via the existing lib/fermion sync, deep-link strategy from our emails to app content, document the boundary (checkout stays on web — store-policy review for external purchases).
4. Path B (Expo): monorepo extraction decision (plan allows Turborepo when a second client arrives), auth via BetterAuth (expo plugin), read APIs via route handlers (OpenAPI'd subset), video via Fermion mobile SDK/DRM, push via Expo Notifications → DeviceToken.
5. Either path: push notification pipeline lights up DeviceToken + Novu (issue #10) mobile channel.
6. Store compliance review: IAP rules for digital goods (major cost driver for Path B checkout — document Google/Apple policy stance for external payments in India).
7. Rollout: closed beta cohort, crash/analytics wiring (Sentry RN / PostHog RN if Path B).

Acceptance criteria

• Decision doc with cost/coverage matrix approved by founder
• Chosen path ships a beta: login, browse enrolled content, play DRM video offline (if supported), receive push
• DeviceTokens registered and push delivered via the notification facade
• Store-policy risks (IAP) documented with the mitigation chosen
• Deep links from notification emails open the right screen

Dependencies / sequencing

• Issue #10 (notifications) first; Fermion relationship from MVP M4
• Path B implies the Turborepo restructure — schedule deliberately

Start by reviewing the existing lib/fermion sync, DeviceToken and notification facade, then evaluate Fermion's covered surfaces against the differentiated learner flows listed in the issue. Produce the decision and cost/coverage matrix, document the IAP and deep-link constraints, and verify the selected path against the beta acceptance criteria and Issue #10 dependency.