feat(scouts): link scout findings to their inbox report

[andrewm4894]

Problem

When you open an inbox report you can see the findings that contributed to it. There was no way to do the reverse: looking at a finding on the Scout page, you couldn't tell which inbox report (if any) it ended up in. The emission card literally said "report assignment isn't traceable here yet."

What this does

Each scout finding now shows a chip linking to the inbox report its signal grouped into — the reverse of the report's evidence list. Clicking it opens the report in the Inbox.

It's best effort: the chip only appears when the reverse lookup resolves a report. Findings that haven't grouped yet, were de-duplicated away, or whose signal was deleted just render as before.

Depends on the backend endpoint in PostHog/posthog#63817 (GET /api/projects/{team_id}/signals/scout/runs/{run_id}/emissions/reports/). Until that ships, the lookup returns nothing and the cards fall back to the existing note — safe to merge independently.

Changes

• api-client — ScoutEmissionReportLink / LinkedSignalReport types + listScoutEmissionReports(projectId, runId).
• useScoutEmissionReports — per-run reverse-lookup query, loaded alongside useScoutRunEmissions in RunEmissions. A failure here is non-fatal — the cards still render, just without the chip.
• ScoutLinkedReportChip — footer chip on the emission card; opens the linked report in the Inbox.
• useOpenInboxReport — extracted from useInboxDeepLink (fetch report by id, seed the detail cache, reset filters, navigate to the right tab — Pulls if it has an implementation PR, otherwise Reports) and reused by the chip, so the deep-link handler and the chip share one proven path. useInboxDeepLink now just wires the tRPC subscription to it.
• ScoutEmissionCard — new optional linkedReport prop; renders the chip and drops the "not traceable yet" note when a link exists.
• analytics-events — new open_linked_report scout action type + report_status property.

Design notes

• Batch, not per-finding — one reverse-lookup query per run (matching how emissions are already fetched per run), keyed client-side by source_id.
• Reuses the deep-link open flow rather than a naive navigate, so the chip lands on the correct tab and primes the cache the same way an external posthog-code://inbox/<id> link does.

Testing

• pnpm typecheck (full repo) and Biome pass via pre-commit.
• No UI tests added: the scouts feature has no existing component test harness, and the only new logic is a trivial source_id → report map (covered by typecheck) — consistent with the inbox guidance to keep tests on pure logic.
• Manual verification pending the backend endpoint landing.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 4f7ce5a.}

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/ui/src/features/scouts/components/ScoutSignalsSection.tsx:108-112
`reportBySourceId` is reconstructed on every render of `RunEmissions`. It only needs to change when `emissionReports` changes, so it should be wrapped in `useMemo`.

```suggestion
  const reportBySourceId = useMemo(
    () =>
      new Map(
        (emissionReports ?? [])
          .filter((link) => link.report)
          .map((link) => [link.source_id, link.report]),
      ),
    [emissionReports],
  );
```

_{Reviews (1): Last reviewed commit: "feat(scouts): link scout findings to the..." | Re-trigger Greptile}

[github-actions]

Clean additive feature — extracts shared logic into useOpenInboxReport, adds a non-fatal best-effort report chip to scout emission cards, and properly uses useMemo (addressing the resolved bot comment). No architecture violations, no breaking changes, no security concerns.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4f7ce5a9ce

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Route run reports to the run detail

When the fetched report has a run-only status (potential, candidate, in_progress, pending_input, or failed), this branch still sends it to /code/inbox/reports/$reportId because only PRs are special-cased. Those reports are excluded from the Reports tab by isReportTabReport, and the run detail route is the one that renders the task log, so clicking a scout linked-report chip for an active/failed run lands on the wrong inbox surface. Add a run-status branch before the reports fallback.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Swallow 404s for the optional scout lookup

When this client is deployed against a backend before the new emissions/reports/ action exists, scoutGet uses the shared fetcher, which throws on any non-2xx in packages/api-client/src/fetcher.ts, so this call rejects with a 404 instead of producing an empty link list. Since useScoutEmissionReports mounts one query per visible emitted run, opening a scout page on that backend will generate failing API requests rather than the intended quiet fallback; catch 404 here and return [] if the endpoint is optional.

Useful? React with 👍 / 👎.