These three are quite similar so I’d merge them into one “user” table. Unique fields could be in separate 1:1 table or stored in the same table. Separate table is more correct. Same table is a bit simpler.
It really depends on your application as well as the domain, there are certain question you should ask before you make major changes in your design. I always start small and continue building on as time goes, thinking about future changes is logical at the same time you need to weight how much more time and effort you going to need to make your app future proof.
I think any one of the above could be a solution, but I think 3rd one gives you more flexibility in terms of future changes you can always add more fields on the fly without duplicating.
users table have a very basic and limited set of fields which are common/shared across all 3 types.
users
email
username
password
active
timestamps
you could move your additional fields to a seperate table which can be used for
your n:m fields as well as the unique ones perhaps called fields/attributes.
for example user type admin with id 1 might have firstname,lastname,birthday which can be represented by another link table like so
user_field
1, 1
1, 2
1, 7
fields
firstname
lastname
nickname
details
gender
choice
birthday
comission
phone
phone 2
phone 3
field values can be stored in a separate table which you can retrieve based on the users -> fields.