feat: implement role-based access control for miniapp

- Introduced a new roles table in the database to manage user roles ('user' and 'admin') for access control.
- Updated the user model to include a foreign key reference to the roles table, allowing for role assignment.
- Enhanced command handlers to support the `/set_role` command for admins to assign roles to users.
- Refactored access control logic to utilize role checks instead of username/phone allowlists, improving security and maintainability.
- Updated documentation to reflect changes in access control mechanisms and role management.
- Added unit tests to ensure correct functionality of role assignment and access checks.

.env.example

@@ -3,12 +3,13 @@ DATABASE_URL=sqlite:///data/duty_teller.db
 MINI_APP_BASE_URL=
 HTTP_PORT=8080
 
-# Miniapp access: comma-separated Telegram usernames (no @). Empty = no one allowed.
-ALLOWED_USERNAMES=username1,username2
+# Access: roles are assigned in the DB by an admin via /set_role. When a user has no role in DB,
+# ADMIN_USERNAMES and ADMIN_PHONES act as fallback for admin only. ALLOWED_* are not used for access.
+ALLOWED_USERNAMES=
 ADMIN_USERNAMES=admin1,admin2
 
-# Optional: allow by phone (user sets phone via /set_phone in bot). Comma-separated; normalized to digits for comparison.
-# ALLOWED_PHONES=79001234567,79007654321
+# Optional: admin fallback by phone (user sets phone via /set_phone). Comma-separated; digits only for comparison.
+# ALLOWED_PHONES=
 # ADMIN_PHONES=79001111111
 
 # Dev only: set to 1 to allow calendar without Telegram initData (insecure; do not use in production).