Refactor EmailAccount deactivated field into granular send/receive controls

[scanner]

Description

Refactor the EmailAccount.deactivated boolean field into more granular control fields to better manage account capabilities.

Current behavior

Currently "deactivated" means:

• Account can still receive email
• Account can be configured via UI and REST API
• Account CANNOT send email

New behavior

• Add is_send_enabled field: Controls whether account can send email
  • Can ONLY be modified from admin interface by admins
• Add is_receive_enabled field: Controls whether account can receive email
  • CAN be modified from EmailAccount UI and REST API by the user
• Redefine deactivated field: When True, account cannot:
  • Send email (regardless of is_send_enabled setting)
  • Be modified via UI or REST API (EXCEPT toggling is_receive_enabled)
  • Can ONLY be modified from admin interface by admins
  • NOTE: User login is controlled by Users, not EmailAccounts - users can still log in
  • NOTE: Deactivated accounts CAN still receive email (if is_receive_enabled is True)

Permission summary

• Admin interface: Can modify deactivated, is_send_enabled, is_receive_enabled
• EmailAccount UI/REST API: Can ONLY modify is_receive_enabled (even if account is deactivated)

Tasks

• Add is_send_enabled and is_receive_enabled fields to EmailAccount model with migration
• Update SMTP send logic to check both deactivated and is_send_enabled
• Update webhook/receive logic to check is_receive_enabled
• Update REST API permissions to prevent modification of deactivated accounts (except is_receive_enabled)
• Update EmailAccount UI to allow toggling is_receive_enabled even when deactivated
• Update EmailAccount UI to prevent other modifications when deactivated
• Update admin interface to show new fields (only place deactivated and is_send_enabled can be modified)
• Add data migration to set initial values based on current deactivated state
• Write tests for new permission checks
• Update documentation