Permission system: staff roles, player roles

Description

A permission system is needed to gate admin commands, dev mode, and future cosmetics to the appropriate roles. Minestom has no built-in permission backend — we need a lightweight role-based system.

Acceptance Criteria

• Roles defined: player (default), moderator, admin, developer
• Roles are stored in the ElytraPlayerEntity DB record as a string field
• On player join, their role is loaded and applied as a Minestom permission group
• voyager.admin permission maps to admin and developer roles
• voyager.dev permission maps to developer role only
• /role set <player> <role> command for admins to change roles (requires voyager.admin)
• Role changes persist to DB immediately

Technical Details

• Minestom Permission API: player.addPermission(new Permission("voyager.admin"))
• No third-party permission plugin needed — custom PermissionService in server
• Role is loaded async on join and applied before the player entity enters any phase

Dependencies

• "Persist player profiles on first join" (Alpha) provides the DB entity to extend

Estimate

M

Read the existing ElytraPlayerEntity DB record and the server’s player-join flow first, then review the Minestom Permission API and identify where a custom PermissionService belongs. Trace the dependency on first-join profile persistence before implementing the role command. Done means roles load before phase entry, permissions are applied, admin changes persist immediately, and all listed role mappings work.