feat: roles/permissions system and Nostr profile display on admin users

Introduce granular role-based permissions with SuperAdmin env override, admin roles UI, and permission-gated API routes. Fix admin user Nostr metadata by batching relay profile fetches, normalizing npub pubkeys to hex, and adding reusable NostrAvatar/useNostrProfile components.

Co-authored-by: Cursor <cursoragent@cursor.com>

README.md

@@ -31,7 +31,7 @@ cp .env.example backend/.env
 cp .env.example frontend/.env.local
 ```
 
-Edit `backend/.env` with your admin pubkeys and a secure JWT secret.
+Edit `backend/.env` with your SuperAdmin pubkeys (`SUPERADMIN_PUBKEYS`) and a secure JWT secret.
 
 ### 3. Set up database
 
@@ -91,15 +91,54 @@ npm run dev
 | PATCH | /api/meetups/:id | Update meetup |
 | POST | /api/moderation/hide | Hide content |
 | POST | /api/moderation/block | Block pubkey |
+| GET | /api/auth/me | Current user's effective role and permissions |
 | GET | /api/users | List users |
-| POST | /api/users/promote | Promote user |
+| PUT | /api/users/:pubkey/role | Assign a role to a user |
+| GET | /api/admin/permissions | Permission registry (keys, labels, groups) |
+| GET | /api/admin/roles | Each role and its permission set |
+| PUT | /api/admin/roles/:role/permissions | Update a role's permissions |
 | GET | /api/categories | List categories |
 | POST | /api/categories | Create category |
 
-## Roles
+## Roles and permissions
 
-- **Admin**: Full access. Defined by pubkeys in `.env`
-- **Moderator**: Content moderation. Assigned by admins via dashboard.
+Access is controlled by an ordered role hierarchy backed by a runtime-editable,
+granular permission system. From highest to lowest:
+
+1. **SuperAdmin** sourced only from the `SUPERADMIN_PUBKEYS` env var. Always has
+   every permission. Cannot be created, edited, demoted, or removed through the
+   UI. This replaces the old "admin set in env" concept. If `SUPERADMIN_PUBKEYS`
+   is unset, the app falls back to the legacy `ADMIN_PUBKEYS` variable.
+2. **Admin** highest role assignable through the dashboard.
+3. **Moderator**
+4. **Writer**
+5. **Guest** the fallback for any logged-in pubkey with no assigned role. Guest is
+   not a stored record, it is simply the absence of a role.
+
+Each assignable role (Admin, Moderator, Writer) maps to a set of permission keys
+stored in the `RolePermission` table. SuperAdmins manage these from the dashboard
+**Roles** page, which renders a permission-by-role matrix. The dashboard nav and
+actions are gated on the current user's resolved permissions, not on role names.
+
+### Safeguards
+
+- SuperAdmin is never assignable through the UI or API. Only the env var grants it.
+- A user cannot assign a role at or above their own, or modify a SuperAdmin.
+- A user cannot grant a role a permission they do not themselves hold.
+- A user cannot remove their own `users.assign_role` or `roles.edit_permissions`.
+  SuperAdmin (env-sourced) is always the recovery path.
+- Unknown role values and permission keys are rejected by the server.
+
+### Adding a new permission key
+
+1. Add an entry to `PERMISSIONS` in
+   [backend/src/constants/permissions.ts](backend/src/constants/permissions.ts)
+   with a `key`, `label`, and `group`.
+2. The key automatically appears in `GET /admin/permissions` and the Roles matrix
+   page, so no UI changes are needed.
+3. Apply it to the relevant endpoints with the `requires('<key>')` guard.
+4. Optionally grant it to roles by default in `DEFAULT_ROLE_PERMISSIONS` (used by
+   the seed) and in the migration so fresh and existing databases get it.
 
 ## License