cleanup: trim bloated multi-line comments across the project

campaigns/models.py

@@ -96,24 +96,12 @@ class CampaignDelivery(models.Model):
         ordering = ['-created_at']
         constraints = [
             # جلوگیریِ race condition: اگه execute_campaign() برای همون
-            # campaign هم‌زمان (دو پراسس/ریکوئستِ موازی) اجرا بشه، هر دو
-            # می‌تونن قبل از اینکه هرکدوم رکوردی بسازن از چکِ
-            # already_sent رد بشن (TOCTOU) و برای یک کاربر دو بار
-            # send_sms/notify صدا زده بشه. این unique constraint دقیقاً
-            # همون چیزی رو در سطحِ دیتابیس تضمین می‌کنه که چکِ اپلیکیشن‌
-            # لایه فرض می‌کرد ولی گارانتی نمی‌داد: برای هر
-            # (campaign, user_id, channel) در آنِ واحد حداکثر یک رکوردِ
-            # «فعال یا موفق» (pending یا sent) می‌تونه وجود داشته باشه.
-            # وقتی دو تلاشِ هم‌زمان می‌خوان برای همون کاربر رکورد pending
-            # بسازن، دومی روی این constraint با IntegrityError شکست
-            # می‌خوره و در execute_campaign() به‌عنوانِ «این کاربر توسطِ
-            # یک اجرای دیگه claim شده» skip می‌شه — پس send_sms/notify
-            # دوباره صدا زده نمی‌شه.
-            #
-            # status=failed عمداً از این constraint مستثنا شده تا رفتارِ
-            # retryِ فعلی (ساختنِ یک رکوردِ pending جدید بعد از یک تلاشِ
-            # ناموفق) دست‌نخورده بمونه: یک رکوردِ failed دیگه «فعال» حساب
-            # نمی‌شه، پس جای رکوردِ جدید رو برای تلاشِ بعدی باز می‌ذاره.
+            # campaign هم‌زمان اجرا بشه، این constraint تضمین می‌کنه حداکثر
+            # یک رکوردِ «فعال یا موفق» (pending/sent) به‌ازای هر
+            # (campaign, user_id, channel) باشه؛ تلاشِ دومِ هم‌زمان با
+            # IntegrityError شکست می‌خوره و به‌عنوانِ claim‌شده skip می‌شه.
+            # status=failed عمداً مستثناست تا retry (ساختِ pendingِ جدید
+            # بعد از شکست) دست‌نخورده بمونه.
             UniqueConstraint(
                 fields=['campaign', 'user_id', 'channel'],
                 condition=Q(status__in=['pending', 'sent']),