Count work_products toward a run's deliverable judgment

The deliverable check used to compare a run against knowledge entries,
documents, and substantial task comments only, so a research or content
task that produced its output as a markdown file on disk (via
write/edit/bash) stayed pinned in_progress even though the deliverable
was already sitting in `work_products`.

Split the DB query into `collectRunDeliverableSignals`, which returns
the four surfaces (knowledge / document / work product / substantial
comment) explicitly, and push the per-task-type acceptance logic into
`automation-run-completion`. Each task type declares which signal set
counts as a valid deliverable: content tasks now require a document or
an on-disk artifact and will not advance on a knowledge entry alone;
research and general accept any of the four; code and management
preserve their broader surface. Tests updated to cover the new signal
and the content/knowledge rejection case.

src/main/database.ts

@@ -124,7 +124,9 @@ export class AppDatabase extends AppDatabaseBase {
   saveSprint(input: { id?: string | null; companyId: string; name: string; goal?: string; startDate: string; endDate: string; status?: string; retrospectiveNotes?: string; velocityPoints?: number; completedPoints?: number }) { return this.knowledgeMod.saveSprint(input); }
   deleteSprint(id: string, companyId: string) { this.knowledgeMod.deleteSprint(id, companyId); }
   listSprints(companyId: string) { return this.knowledgeMod.listSprints(companyId); }
-  runProducedDeliverable(runId: string, companyId: string, taskId: string) { return this.knowledgeMod.runProducedDeliverable(runId, companyId, taskId); }
+  collectRunDeliverableSignals(runId: string, companyId: string, taskId: string) {
+    return this.knowledgeMod.collectRunDeliverableSignals(runId, companyId, taskId);
+  }
 
   // ─── Automation ────────────────────────────────────────────────────────────