Featurebase: role-based Messenger identify (admin / trainer / coordinator / student)

Goal

Role-based Featurebase Messenger streams (non-Enterprise): identify users with rtopilotRole / org context so Admin vs Trainer/Coordinator vs Student get different routing and escalation. One Help Center (shared) — manage content carefully so admin-only guides are not published for learners.

Context

Manning 28 Sep 2026: not on Enterprise → no multi-brand / multi-HC. Chose roles+identity over second workspace.

Current

• Featurebase JWT + Messenger only for admin portal (FeaturebaseInitialiser, mustHaveAdminRights on FEATUREBASE_AUTH).
• Students: Support → RTO email modal. Trainer/Coord: in-app support form.

Implementation (code)

1. Allow FEATUREBASE_AUTH for any fully logged-in user.
2. JWT claims: email, userId, name, custom rtopilotRole (admin|trainer|coordinator|student for current portal), portal, companies (current org).
3. Mount Featurebase on trainer/coordinator/student portals.
4. Widgets: Admin = messenger + feedback + changelog; Trainer/Coord = messenger (+ feedback); Student = messenger only; keep student RTO-email path for ops.
5. SupportSidebarItem: open Featurebase messenger when initialised for all those roles.

Featurebase dashboard (Manning)

1. Settings → Users → Custom attributes: create rtopilotRole, portal (and company fields if needed).
2. Inbox views/rules: route by rtopilotRole (e.g. admin → Support; learner product → Support tagged Learner; ops still RTO-side for students).
3. HC content discipline: keep admin-only articles out of the public Help Center (or unpublished) until Enterprise multi-HC.

Blocker

Cloud agent launch failed 28 Sep: Cursor usage exhausted — need on-demand enabled to ship the PR.

Related: RTOP-396 (Done — original widget install).