Problem

The type argument in notify.send() is currently optional and defaults to None. This forces the entire codebase to carry fallback/conditional logic to handle type=None notifications across models, handlers, utils, types, and tasks. This adds unnecessary complexity, reduces type safety, and can lead to inconsistent notification behavior (no template rendering, no preference filtering, no proper email subject).\

Describe the solution you'd like

1. Make type required in notify.send() — drop the type=None default so callers must always specify a notification type. (The signal definition itself can't enforce required args, but we can validate in the handler.)
2. Make Notification.type non-nullable — change the field from null=True to null=False on the AbstractNotification model, with a database migration.
3. Remove all type=None guard logic for Notification — clean up every branch that checks if self.type: / if not self.type: / if notification_type is None / if not notification_type: in contexts specific to notification creation and rendering, not notification settings.
4. Drop tests that verify type=None behavior for notifications, and update any notify.send() calls in tests that omit type.

Additional context

The type field has been nullable since it was introduced in migration 0003_notification_notification_type.py. At the time it made sense to support "untyped" notifications, but as the notification types system has matured, every real-world use of the library passes a type. Dropping None support simplifies the codebase significantly.