Inbox (desktop/mobile): Discuss and Scout runs are hidden from a report's Runs section, and a Discuss PR can be duplicated

Problem

On web, a report's Runs section lists every associated task run, including Discuss and Scout runs (deriveTaskPurpose in frontend/src/scenes/inbox/components/detail/artefactTypes.ts maps them to Scout / Signals — Discussion).

Desktop and mobile drop them entirely. derivePurpose in products/desktop/packages/ui/src/features/inbox/hooks/useReportTasks.ts returns null for any product=signals run that isn't research or implementation:

if (taskRun.product === "signals") {
  if (taskRun.type === "research") { … }
  if (taskRun.type === "implementation") { … }
  // repo_selection runs are plumbing, not report work — never displayed
  return null;
}

The comment only justifies excluding repo_selection, but the code excludes discussion and scout too. Since null entries are filtered out of reportTasks, a report whose only work was a Discuss task shows an empty Runs section on desktop and mobile while web shows the run and its transcript.

Reproducible on report 019fb453-08d0-7a33-be83-45bdbb10d5b5 (inbox), which has scout and discussion runs and no implementation run.

Second, more serious symptom: duplicate PRs

findContinuableImplementationTask (same file) only ever considers purpose === "implementation":

const implementation = reportTasks.filter((t) => t.purpose === "implementation");

Its own docstring explains the intent — "re-engaging the report should resume it rather than spin up a duplicate PR", and it deliberately trusts the task over a possibly-stale report.implementation_pr_url. But a Discuss task that already shipped a PR is invisible to it on both counts: it isn't in reportTasks at all, and (see PostHog/posthog#76346) the report's implementation_pr_url is null for exactly this case.

So on desktop, a report whose Discuss task already opened a PR looks completely untouched, canCreateImplementationPr still returns true, and re-engaging it starts a fresh implementation task — a second PR for work that's already done.

Suggested fix

• In derivePurpose, exclude only repo_selection (matching the comment and web's deriveTaskPurpose), letting discussion and scout fall through to other with a humanized label.
• Widen findContinuableImplementationTask so a non-implementation run that already produced a pr_url counts as continuable — the PR's existence is the signal that matters here, not the run's label.

Acceptance criteria

• Desktop and mobile Runs sections list discussion and scout runs with the same labels web uses; repo_selection stays hidden.
• A report whose only PR-bearing run is a Discuss run resumes that task on re-engagement instead of starting a new implementation task.
• Unit coverage for derivePurpose across all (product, type) pairs, and for findContinuableImplementationTask picking up a PR-bearing non-implementation run.

Related: PostHog/posthog#76346 (same underlying blind spot, backend side).

Start in products/desktop/packages/ui/src/features/inbox/hooks/useReportTasks.ts, reading derivePurpose and findContinuableImplementationTask, then compare their behavior with frontend/src/scenes/inbox/components/detail/artefactTypes.ts. Run the relevant unit tests or add coverage for all product/type pairs and PR-bearing non-implementation runs. Done means discussion and scout runs appear with matching labels, repo_selection remains hidden, and re-engagement resumes a task that already produced a PR.