fix(downloads): derive title clamp from the column + real-Postgres regression

Address review findings on the title-clamp: TITLE_MAX_LEN now reads the length straight
from Notification.title so the clamp can't drift from the column a migration would change
(single source of truth). Add a db-lane test that actually commits a >255-char title into
Postgres (end-to-end proof the truncation is gone, not just the clamp logic) and one that
asserts the constant tracks the column width.

backend/app/notifications.py

@@ -14,12 +14,13 @@ from app.models import Notification
 # rows are never pruned (the user hasn't seen them yet).
 READ_SOFT_CAP = 200
 
-# Hard limit of the Notification.title column (String(255)). Titles are only an English
-# fallback — the client renders the translated message from `data` — so clamping an
-# over-long one (e.g. a FB/IG reel whose "title" is the whole caption, hundreds of chars)
-# is harmless to the UI and prevents a StringDataRightTruncation that would abort the
-# caller's whole transaction (the batched download_gc run in particular).
-TITLE_MAX_LEN = 255
+# Hard limit of the Notification.title column, read straight from the model so the clamp
+# can never drift from the actual column width (a later migration is the single source of
+# truth). Titles are only an English fallback — the client renders the translated message
+# from `data` — so clamping an over-long one (e.g. a FB/IG reel whose "title" is the whole
+# caption, hundreds of chars) is harmless to the UI and prevents a StringDataRightTruncation
+# that would abort the caller's whole transaction (the batched download_gc run in particular).
+TITLE_MAX_LEN = Notification.__table__.c.title.type.length
 
 
 def create_notification(