feat(intake): run the drafting worker after a submission and on a sweep (#223)

Two drivers. The call after a successful submission means a draft is usually waiting by the time anybody looks; the five-minute sweep means a restart mid-draft is recoverable rather than a permanently stalled row, and picks up whatever the first call missed.

Neither is awaited. A slow or failing model must not become a failed upload for someone who did nothing wrong, which is the whole reason drafting does not happen inline — the cost of a dropped call is a few minutes' delay, not a lost submission.

Both catch for themselves. The comment beside the existing schedulers points out that `void` is only safe because those functions handle their own errors, and draftQueued does not: its first query can reject, and an escaping rejection would take the container down.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/src/routes/intake.ts

@@ -4,6 +4,7 @@ import { asyncRoute } from '../asyncRoute';
 import { hashToken } from '../uploadLinks';
 import { uploadImages, verifyUploadedImages, insertItemImages } from '../imageUpload';
 import { intakeViewLimiter, intakeSubmitLimiter } from '../rateLimit';
+import { draftQueued } from '../intake/draftingWorker';
 
 const router = Router();
 
@@ -148,6 +149,14 @@ router.post(
       }
 
       await client.query('COMMIT');
+
+      // Deliberately not awaited, and catching for itself. A slow or failing
+      // model must not become a failed upload for someone who did nothing
+      // wrong, which is the whole reason drafting does not happen inline. The
+      // sweeper picks up anything this misses, so the cost of it failing here
+      // is a few minutes' delay rather than a lost submission.
+      void draftQueued(1).catch((err) => console.error('[drafting] after submission:', err));
+
       // No item id in the response: the sender has no business knowing about
       // the catalogue, and nothing they could do with it.
       res.status(201).json({ ok: true });