fix: drop \{ not: null }\ filters — Prisma 7 rejects them at runtime

PrismaClientValidationError ('Argument \`not\` must not be null') hit at
runtime when notifications-bridge mounted post-M12 schema change.
Although StringNullableFilter typings allow \`not: null\`, the v7 query
engine rejects it.

Removed the WHERE-side filter in 3 places — null-narrowing already
happens client-side via flatMap / Boolean filter:
- components/notifications/notifications-bridge.tsx
- app/api/realtime/notifications/route.ts
- lib/insights/verify-stats.ts (task_id filter)

Idea-questions / idea-jobs will be routed via separate channels in
T-502 + T-507; for now, story-question + task-job paths simply ignore
NULL rows in their post-fetch mapping.

Tests: 479/479 green; tsc clean.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

lib/insights/verify-stats.ts

@@ -40,7 +40,9 @@ export async function getVerifyResultStats(
     status: 'DONE' as const,
     verify_result: { not: null as null },
     finished_at: { gt: cutoff },
-    task_id: { not: null },
+    // Note: task_id can now be NULL on idea-jobs (M12). The toTopJob mapper
+    // filters them out via .filter(Boolean). Keeping a where-side filter
+    // (`task_id: { not: null }`) is rejected by Prisma 7 runtime.
   }
 
   const [grouped, rawEmpty, rawDivergent] = await Promise.all([