fix(email): wire the settings status card, and cap-aware truncation

Codex review round 4 on #1273.

Settings → Status rendered a green check for the email processor
unconditionally, against an API field that was itself the literal 'active'.
Both ends were lying and only one of them got fixed: adminSystem started
reporting the real state in an earlier commit, but StatusTab never read it, so
the second place an admin looks to find out why mail is not arriving still said
everything was fine. It now shows stopped and degraded, with the reason.

The truncation flag missed the case it most needed to cover. The loop broke on
the 200-row report cap before the flag could be set, so 201+ overdue rows came
back as exactly 200 with scanTruncated false -- a partial report presented as
complete. It is now set whenever rows were left unexamined.

The grace-window comment claimed the processor clears ~6000 rows inside the
window. It clears on the order of 100: ten rows a pass, one pass a minute. The
comment now says so, and says why the processor's own state is reported above
the list rather than inferred from it -- "running, last pass sent 10" next to a
backlog reads very differently from "not running" next to the same backlog.

One round-4 finding is NOT fixed, deliberately, and is written up at the retry
route. Clearing scheduled_at leaves created_at at the original enqueue time, so
a retried old row appears in the waiting list immediately, looking overdue,
until the processor sends it. Restarting that clock needs a timestamp written
there and no shape works: a Date matches how queueEmail writes the column and
how processEmailQueue compares it, but jest's sandbox Dates store as
"[object Object]" (CLAUDE.md) so it cannot be tested; an ISO string tests fine
but stores as TEXT, which SQLite then orders above the numeric bound in the
processor's own pickup query, leaving the row unsendable. A requeued_at column
would settle it. Cosmetic either way, and not worth risking a stuck row.

1 more test, failing before this commit.

frontend/src/features/settings/tabs/StatusTab.tsx

@@ -10,6 +10,7 @@ import {
   Ruler,
   CalendarClock,
   RotateCw,
+  AlertTriangle,
 } from 'lucide-react';
 import { Button, Card, Input } from '../../../components/common';
 import { useTranslation } from 'react-i18next';
@@ -585,12 +586,30 @@ export const StatusTab: React.FC<StatusTabProps> = ({
                 </div>
                 <p className="text-xs text-neutral-600 dark:text-neutral-400">{t('settings.systemStatus.expirationCheckerDesc')}</p>
               </div>
+              {/* #1262 — this card used to render a green check unconditionally,
+                  against an API field that was itself the literal 'active'. Both
+                  ends now tell the truth: a stopped or bailing processor is the
+                  reason queued mail never arrives, and this is one of the two
+                  places an admin looks to find that out. */}
               <div className="bg-neutral-50 dark:bg-neutral-800 rounded-lg p-4">
                 <div className="flex items-center justify-between mb-2">
                   <p className="text-sm font-medium text-neutral-700 dark:text-neutral-300">{t('settings.systemStatus.emailProcessor')}</p>
-                  <CheckCircle className="w-5 h-5 text-green-600" />
+                  {systemStatus?.services?.emailProcessor?.status === 'active' ? (
+                    <CheckCircle className="w-5 h-5 text-green-600" />
+                  ) : (
+                    <AlertTriangle className="w-5 h-5 text-red-600" />
+                  )}
                 </div>
-                <p className="text-xs text-neutral-600 dark:text-neutral-400">{t('settings.systemStatus.emailProcessorDesc')}</p>
+                <p className="text-xs text-neutral-600 dark:text-neutral-400">
+                  {systemStatus?.services?.emailProcessor?.status === 'stopped'
+                    ? t('settings.systemStatus.emailProcessorStopped',
+                      'Not running — queued emails are written but nothing sends them.')
+                    : systemStatus?.services?.emailProcessor?.status === 'degraded'
+                      ? t('settings.systemStatus.emailProcessorDegraded',
+                        'Running, but the last pass could not send: {{error}}',
+                        { error: systemStatus?.services?.emailProcessor?.lastError })
+                      : t('settings.systemStatus.emailProcessorDesc')}
+                </p>
               </div>
             </div>
 

frontend/src/i18n/locales/de.json

@@ -1968,7 +1968,9 @@
       "pending": "Ausstehend",
       "sent": "Gesendet",
       "failed": "Fehlgeschlagen",
-      "lastUpdate": "Letzte Aktualisierung"
+      "lastUpdate": "Letzte Aktualisierung",
+      "emailProcessorStopped": "Läuft nicht — eingereihte E-Mails werden geschrieben, aber niemand versendet sie.",
+      "emailProcessorDegraded": "Läuft, aber der letzte Durchlauf konnte nicht senden: {{error}}"
     },
     "photoDimensions": {
       "title": "Foto-Abmessungen",

frontend/src/i18n/locales/en.json

@@ -1331,7 +1331,9 @@
       "pending": "Pending",
       "sent": "Sent",
       "failed": "Failed",
-      "lastUpdate": "Last update"
+      "lastUpdate": "Last update",
+      "emailProcessorStopped": "Not running — queued emails are written but nothing sends them.",
+      "emailProcessorDegraded": "Running, but the last pass could not send: {{error}}"
     },
     "photoDimensions": {
       "title": "Photo Dimensions",

frontend/src/services/settings.service.ts

@@ -164,7 +164,9 @@ export interface SystemStatus {
   services: {
     fileWatcher: { status: string };
     expirationChecker: { status: string };
-    emailProcessor: { status: string };
+    // 'active' | 'degraded' | 'stopped' (#1262). Was a hardcoded 'active'
+    // until the processor started reporting what it actually did.
+    emailProcessor: { status: string; lastRunAt?: string | null; lastError?: string | null };
   };
   timestamp: string;
 }